< draft-ietf-teas-actn-info-model-02.txt   draft-ietf-teas-actn-info-model-03.txt >
Teas Working Group Young Lee Teas Working Group Young Lee
Internet Draft Huawei Internet Draft Huawei
Intended status: Informational Sergio Belotti Intended status: Informational Sergio Belotti
Nokia Nokia
Expires: December 30, 2017 Expires: April 10, 2018
Dhruv Dhody Dhruv Dhody
Huawei Huawei
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Bin Young Yun Bin Yeong Yoon
ETRI ETRI
June 30, 2017 October 11, 2017
Information Model for Abstraction and Control of TE Networks (ACTN) Information Model for Abstraction and Control of TE Networks (ACTN)
draft-ietf-teas-actn-info-model-02.txt draft-ietf-teas-actn-info-model-03.txt
Abstract Abstract
This draft provides an information model for Abstraction and Control This draft provides an information model for Abstraction and Control
of Traffic Engineered (TE) networks (ACTN). of Traffic Engineered (TE) networks (ACTN).
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 30, 2017. This Internet-Draft will expire on April 10, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction ..................................................3
1.1. Terminology...............................................4 1.1. Terminology...............................................4
2. ACTN Common Interfaces Information Model.......................4 2. ACTN Common Interfaces Information Model ......................4
2.1. VN Action Primitives......................................5 3. Virtual Network primitives ....................................6
2.1.1. VN Instantiate.......................................6 3.1. VN Instantiate............................................6
2.1.2. VN Modify............................................6 3.2. VN Modify.................................................7
2.1.3. VN Delete............................................6 3.3. VN Delete.................................................7
2.1.4. VN Update............................................7 3.4. VN Update.................................................7
2.1.5. VN Path Compute......................................7 3.5. VN Compute................................................8
2.1.6. VN Query.............................................7 4. Traffic Engineering (TE) primitives ...........................8
2.1.7. TE Update (for TE resources).........................8 4.1. TE Instantiate............................................9
2.2. VN Objects................................................8 4.2. TE Modify.................................................9
2.2.1. VN Identifier........................................9 4.3. TE Delete.................................................9
2.2.2. VN Service Characteristics...........................9 4.4. TE Topology Update (for TE resources).....................9
2.2.3. VN End-Point........................................11 4.5. Path Compute.............................................10
2.2.4. VN Objective Function...............................12 5. VN Objects ...................................................11
2.2.5. VN Action Status....................................13 5.1. VN Identifier............................................11
2.2.6. VN Associated LSP...................................13 5.2. VN Service Characteristics...............................11
2.2.7. VN Computed Path....................................13 5.3. VN End-Point.............................................14
2.2.8. VN Service Preference...............................13 5.4. VN Objective Function....................................14
2.3. Mapping of VN Primitives with VN Objects.................14 5.5. VN Action Status.........................................15
3. References....................................................15 5.6. VN Topology..............................................15
3.1. Normative References.....................................15 5.7. VN Member................................................15
3.2. Informative References...................................16 5.7.1. VN Computed Path....................................16
4. Contributors..................................................16 5.7.2. VN Service Preference...............................16
Contributors' Addresses..........................................16 6. TE Objects ...................................................17
Authors' Addresses...............................................16 6.1. TE Tunnel Characteristic.................................17
Appendix A: ACTN Applications....................................18 7. Mapping of VN Primitives with VN Objects .....................19
A.1. Coordination of Multi-destination Service 8. Mapping of TE Primitives with TE Objects .....................20
Requirement/Policy.........................................18 9. References ...................................................21
A.2. Application Service Policy-aware Network Operation....20 9.1. Normative References.....................................21
A.3. Network Function Virtualization Service Enabled 9.2. Informative References...................................21
Connectivity...............................................22 10.Contributors .................................................22
A.4. Dynamic Service Control Policy Enforcement for Contributors' Addresses..........................................22
Performance and Fault Management...........................24 Authors' Addresses...............................................22
A.5. E2E VN Survivability and Multi-Layer (Packet-Optical)
Coordination for Protection/Restoration....................25
1. Introduction 1. Introduction
This draft provides an information model for the requirements This draft provides an information model for the requirements
identified in the ACTN requirements [ACTN-Req] and the ACTN identified in the ACTN requirements [ACTN-Req] and the ACTN
interfaces identified in the ACTN architecture and framework interfaces identified in the ACTN architecture and framework
document [ACTN-Frame]. document [ACTN-Frame].
The purpose of this draft is to put all information elements of ACTN The purpose of this draft is to put all information elements of ACTN
in one place before proceeding to development work necessary for in one place before proceeding to development work necessary for
protocol extensions and data models. protocol extensions and data models.
The ACTN reference architecture identified a three-tier control The ACTN reference architecture [ACTN-Frame] identified a three-tier
hierarchy as depicted in Figure 1: control hierarchy as depicted in Figure 1:
- Customer Network Controllers (CNC) - Customer Network Controllers (CNC)
- Multi-Domain Service Coordinator (MDSC) - Multi-Domain Service Coordinator (MDSC)
- Physical Network Controllers (PNC). - Physical Network Controllers (PNC).
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| CNC-A | | CNC-B | | CNC-C | | CNC-A | | CNC-B | | CNC-C |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
\___________ | ____________ _/ \ | /
---------- | CMI ------------ ---------- | CMI ------------
\ | / \ | /
+-----------------------+ +-----------------------+
| MDSC | | MDSC |
+-----------------------+ +-----------------------+
_________/ | \_________ / | \
-------- | MPI ------------____ -------- | MPI ------------
/ | \ / | \
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| PNC | | PNC | | PNC | | PNC | | PNC | | PNC |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
Figure 1: A Three-tier ACTN control hierarchy Figure 1: A Three-tier ACTN control hierarchy
The two interfaces with respect to the MDSC, one north of the MDSC The two interfaces with respect to the MDSC, one north of the MDSC
and the other south of the MDSC are referred to as CMI (CNC-MDSC and the other south of the MDSC are referred to as CMI (CNC-MDSC
Interface) and MPI (MDSC-PNC Interface), respectively. It is Interface) and MPI (MDSC-PNC Interface), respectively. It is
intended to model these two interfaces and derivative interfaces intended to model these two interfaces and derivative interfaces
thereof (e.g., MDSC to MSDC in a hierarchy of MDSCs) with one common thereof (e.g., MDSC to MSDC in a hierarchy of MDSCs) with one common
model. model.
Appendix A provides some relevant ACTN use-cases extracted from
[ACTN-Req]. Appendix A is information only and may help readers
understand the context of key use-cases addressed in [ACTN-Req].
1.1. Terminology 1.1. Terminology
Refer VN, VNS to [ACTN-Frame] and abstraction and abstract topology Refer VN, VNS to [ACTN-Frame] and abstraction and abstract topology
to [RFC7926]. to [RFC7926].
2. ACTN Common Interfaces Information Model 2. ACTN Common Interfaces Information Model
This section provides ACTN common interface information model to This section provides ACTN common interface information model to
describe in terms of primitives, objects, their properties describe in terms of primitives, objects, their properties
(represented as attributes), their relationships, and the resources (represented as attributes), their relationships, and the resources
skipping to change at page 5, line 23 skipping to change at page 5, line 21
hierarchy of MDSCs in which workloads may need to be partitioned to hierarchy of MDSCs in which workloads may need to be partitioned to
multiple MDSCs. multiple MDSCs.
Basic primitives (messages) are required between the CNC-MDSC and Basic primitives (messages) are required between the CNC-MDSC and
MDSC-PNC controllers. These primitives can then be used to support MDSC-PNC controllers. These primitives can then be used to support
different ACTN network control functions like network topology different ACTN network control functions like network topology
request/query, VN service request, path computation and connection request/query, VN service request, path computation and connection
control, VN service policy negotiation, enforcement, routing control, VN service policy negotiation, enforcement, routing
options, etc. options, etc.
At a minimum, the following VN action primitives should be There are two different types of primitives depending of the type of
supported: interface:
- VN Instantiate (See Section 2.1.1. for the description) - Virtual Network primitives at CMI
- Traffic Engineering primitives at MPI
- VN Modify (See Section 2.1.2. for the description) As well described in [ACTN-Frame], at the CMI level, there is no
need for detailed TE information since the basic functionality is to
translate customer service information into virtual network service
operation.
- VN Delete (See Section 2.1.3. for the description) At the MPI level, MDSC has the main scope for multi-domain
coordination and creation of a single e2e abstracted network view
which is strictly related to TE information.
- VN Update ((See Section 2.1.4. for the description) As for topology, this document employs two types of topology:
- VN Path Compute (See Section 2.1.5. for the description) - The first type is referred to as virtual network topology which
is associated a VN. Virtual network topology is a customized
topology for view and control by the customer. See Section 3.1
for details.
- VN Query (See Section 2.1.6. for the description) - The second type is referred to as TE topology which is associated
with provider network operation on which we can apply policy to
obtain the required level of abstraction to represent the
underlying physical network topology.
In addition to VN action primitives, TE Update primitive should also 3. Virtual Network primitives
be supported (See Section 2.1.7. for the description).
Note that all VN action primitives defined above are applicable only This section provides a list of main VN primitives related to
to CMI while TE update primitive is applicable to both CMI and MPI." virtual network which are necessary to satisfy ACTN requirements
specified in [ACTN-REQ]
2.1. VN Action Primitives At a minimum, the following VN action primitives should be
supported:
This section provides a list of main primitives necessary to satisfy - VN Instantiate (See Section 3.1.1. for the description)
ACTN requirements specified in [ACTN-REQ].
<VN Action> describes main primitives. VN Action can be one of the - VN Modify (See Section 3.1.2. for the description)
following primitives: (i) VN Instantiate; (ii) VN Modify; (iii) VN
Delete; (iv) VN Update; (v) VN Path Compute; (vi) VN Query. - VN Delete (See Section 3.1.3. for the description)
- VN Update ((See Section 3.1.4. for the description)
- VN Path Compute (See Section 3.1.5. for the description)
- VN Query (See Section 3.1.6. for the description)
<VN Action> is an object describing the main VN primitives.
VN Action can assume one of the mentioned above primitives values.
<VN Action> ::= <VN Instantiate> | <VN Action> ::= <VN Instantiate> |
<VN Modify> | <VN Modify> |
<VN Delete> | <VN Delete> |
<VN Update> | <VN Update> |
<VN Path Compute> | <VN Path Compute> |
<VN Query> <VN Query>
2.1.1. VN Instantiate All these actions will solely happen at CMI level between Customer
Network Controller (CNC) and Multi Domain Service Coordinator
(MDSC).
3.1. VN Instantiate
<VN Instantiate> refers to an action from customers/applications to <VN Instantiate> refers to an action from customers/applications to
request their VNs. This primitive can also be applied from an MDSC request the creation of VNs. Depending on the agreement between
to a PNC requesting a VN (if the domain the PNC supports can client and provider <VN instantiate> can imply different VN
instantiate the entire VN) or a part of VN elements. Please see the operations and view, depending on the type of VN requested. You can
definition of VN in [ACTN-Frame]. have two types of VN instantiation:
2.1.2. VN Modify VN type 1: Where VN is viewed as a set of edge-to-edge links,
referred as VN members in ACTN terminology.
<VN Modify> refers to an action from customers/applications to VN type 2: Where VN is viewed as a VN-topology which is comprised of
modify an existing VN (i.e., instantiated VN). This primitive can virtual nodes and virtual links. See Section 5.6 for details.
also be applied from an MDSC to a PNC requesting a VN (if the domain
the PNC supports can instantiate the entire VN) or a part of VN
elements.
2.1.3. VN Delete Please see [ACTN-Frame] for details regarding the types of VN.
<VN Delete> refers to an action from customers/applications to 3.2. VN Modify
delete an existing VN. This primitive can also be applied from an
MDSC to a PNC requesting a VN (if the domain the PNC supports can
instantiate the entire VN) or a part of VN elements.
2.1.4. VN Update <VN Modify> refers to an action issued from customers/applications
to modify an existing VN (i.e., an instantiated VN).
<VN Update> refers to any update to the VN that need to be updated 3.3. VN Delete
to the subscribers. VN Update fulfills a push model at CMI level, to
<VN Delete> refers to an action issued from customers/applications
to delete an existing VN.
3.4. VN Update
<VN Update> refers to any update to the VN that needs to be updated
to the customers. VN Update fulfills a push model at CMI level, to
make aware customers of any specific changes in the topology details make aware customers of any specific changes in the topology details
related to VN instantiated. related to VN instantiated.
Note the VN Update means the connection-related information (e.g., VN Update, depending of the type of VN instantiated, can be an
LSPs) update that has association with VNs. update of VN members (edge-to-edge links) in case of VN type 1, or a
virtual topology view update in case of VN type 2.
2.1.5. VN Path Compute The connection-related information (e.g., LSPs) update association
with VNs will be part of the "translation" function that happens in
MDSC to map/translate VN request into TE semantics. This information
will be provided in case customer optionally wants to have more
detailed TE information associated with the instantiated VN.
<VN Path Compute> consists of Request and Reply. Request refers to 3.5. VN Compute
an action from customers/applications to request a VN path
computation. This primitive can also be applied from an MDSC to a
PNC requesting a VN (if the domain the PNC supports can instantiate
the entire VN) or a part of VN elements.
<VN Path Compute> Reply refers to the reply in response to <VN Path <VN Compute> consists of Request and Reply. Request refers to an
Compute> Request. action from customers/applications to request a VN computation.
<VN Path Compute> Request/Reply is to be differentiated from a VN <VN Compute> Reply refers to the reply in response to <VN Compute>
Instantiate. The purpose of VN Path Compute is a priori exploration Request.
to estimate network resources availability and getting a list of
possible paths matching customer/applications constraints. To make
this type of request Customer/application controller can have a
shared (with lower controller) view of an abstract network topology
on which to get the constraints used as input in a Path Computation
request. The list of paths obtained by the request can be used by
customer/applications to give path constrains during VNS
connectivity request and to compel the lower level controller (e.g.
MDSC) to select the path that Client/application controller has
chosen among the set of paths returned by the Path Computation
primitives. The importance of this primitives is for example in a
scenario like multi-domain in which the optimal path obtained by an
orchestrator as sum of optimal paths for different domain controller
cannot be the optimal path in the Client/application controller
prospective. This only applies between CNC and MDSC.
2.1.6. VN Query <VN Compute> Request/Reply is to be differentiated from a VN
Instantiate. The purpose of VN Compute is a priori exploration to
compute network resources availability and getting a possible VN
view in which path details can be specified matching
customer/applications constraints. This a priori exploration may not
guarantee the availability of the computed network resources at the
time of instantiation.
<VN Query> refers to any query pertaining to the VN that has been <VN Query> refers to inquiry pertaining to the VN that has been
already instantiated. VN Query fulfills a pull model and permit to already instantiated. VN Query fulfills a pull model and permit to
get topology view. get topology view.
<VN Query Reply> refers to the reply in response to <VN Query>. <VN Query Reply> refers to the reply in response to <VN Query>.
2.1.7. TE Update (for TE resources) 4. Traffic Engineering (TE) primitives
<TE Update> it is a primitives specifically related to MPI This section provides a list of main TE primitives necessary to
interface to provide TE resource update between any domain satisfy ACTN requirements specified in [ACTN-REQ] related to typical
controller towards MDSC regarding the entire content of any "domain TE operations supported at MPI level.
controller" TE topology or an abstracted filtered view of TE
topology depending on negotiated policy.
<TE Update> ::= [<Abstraction>]<TE-topology...> At a minimum, the following TE action primitives should be
supported:
<TE-topology> ::= <TE-Topology-reference> <Node-list> <Link-list> - TE Instantiate/Modify/Delete
- TE Topology Update (See Section 4.4. for the description)
- Path Compute
<TE Action> is an object describing the main TE primitives.
TE Action can assume one of the mentioned above primitives values.
<TE Action> ::= <TE Instantiate> |
<TE Modify> |
<TE Delete> |
<TE Topology Update> |
<Path Compute> |
All these actions will solely happen at MPI level between Multi
Domain Service Coordinator (MDSC) and Physical Network Controller
(PNC).
4.1. TE Instantiate
<TE Instantiate> refers to an action issued from MDSC to PNC to
instantiate new TE tunnels.
4.2. TE Modify
<TE Modify> refers to an action issued from MDSC to PNC to modify
existing TE tunnels.
4.3. TE Delete
<TE Delete> refers to an action issued from MDSC to PNC to delete
existing TE tunnels.
4.4. TE Topology Update (for TE resources)
<TE Topology Update> is a primitive specifically related to MPI to
provide TE resource update between any domain controller towards
MDSC regarding the entire content of any "domain controller" actual
TE topology or an abstracted filtered view of TE topology depending
on negotiated policy.
See [TE-TOPO] for detailed YANG implementation of TE topology
update.
<TE Topology Update> ::= <TE-topology-list>
<TE-topology-list> ::= <TE-topology> [<TE-topology-list>]
<TE-topology> ::= [<Abstraction>] <TE-Topology-identifier> <Node-
list> <Link-list>
<Node-list> ::= <Node>[<Node-list>] <Node-list> ::= <Node>[<Node-list>]
<Node> ::= <Node> <TE-Termination Points> <Node> ::= <Node> <TE Termination Point-list>
<TE Termination Point-list> ::= <TE Termination Point>
[<TE-Termination Point-list>]
<Link-list> ::= <Link>[<Link-list>] <Link-list> ::= <Link>[<Link-list>]
Where Where
<Abstraction> provides information on level of abstraction (as <Abstraction> provides information on level of abstraction (as
determined a priori). determined a priori).
<TE-topology-reference> ::= information related to the specific te- <TE-topology-identifier> is an identifier that identifies a specific
topology related to nodes and links present in this TE-topology. te-topology, e.g., te-types:te-topology-id [TE-TOPO].
<Node-list> ::= detailed information related to a specific node <Node-list> is detailed information related to a specific node
belonging to a te-topology e.g. te-node-attributes [TE-TOPO]. belonging to a te-topology, e.g., te-node-attributes [TE-TOPO].
<Link-list> ::= information related to the specific link related <Link-list> is information related to the specific link related
belonging to a te-topology e.g. te-link-attributes [TE-TOPO]. belonging to a te-topology, e.g., te-link-attributes [TE-TOPO].
<TE-Termination Points> ::= information details associated to the <TE Termination Point-list> is detailed information
termination point of te-link related to a specific node e.g. associated with the termination points of te-link related to a
interface-switching-capability [TE-TOPO]. specific node, e.g., interface-switching-capability [TE-TOPO].
2.2. VN Objects 4.5. Path Compute
<Path Compute> consists of Request and Reply. Request refers to an
action from MDSC to PNC to request a path computation.
<Path Compute> Reply refers to the reply in response to <Path
Compute> Request.
The context of <path-compute> is described in [Path-Compute].
5. VN Objects
This section provides a list of objects associated to VN action This section provides a list of objects associated to VN action
primitives. primitives.
2.2.1. VN Identifier 5.1. VN Identifier
<VN Identifier> is a unique identifier of the VN. <VN Identifier> is a unique identifier of the VN.
2.2.2. VN Service Characteristics (applicable only to CMI) 5.2. VN Service Characteristics
VN Service Characteristics describes the customer/application VN Service Characteristics describes the customer/application
requirements against the VNs to be instantiated. requirements against the VNs to be instantiated.
<VN Service Characteristics> ::= <VN Connectivity Type> <VN Service Characteristics> ::= <VN Connectivity Type>
(<VN Traffic Matrix>...) (<VN Traffic Matrix>...)
<VN Survivability> <VN Survivability>
skipping to change at page 9, line 36 skipping to change at page 11, line 41
addition to the classical type of services (e.g. P2P/P2MP etc.), addition to the classical type of services (e.g. P2P/P2MP etc.),
ACTN defines the "multi-destination" service that is a new P2P ACTN defines the "multi-destination" service that is a new P2P
service where the end points are not fixed. They can be chosen among service where the end points are not fixed. They can be chosen among
a list of pre-configured end points or dynamically provided by the a list of pre-configured end points or dynamically provided by the
CNC. CNC.
<VN Traffic Matrix> ::= <Bandwidth> <VN Traffic Matrix> ::= <Bandwidth>
[<VN Constraints>] [<VN Constraints>]
The VN Traffic Matrix represents the traffic matrix parameters The VN Traffic Matrix represents the traffic matrix parameters for
required against the service connectivity required and so the VN the required the service connectivity. Bandwidth is a mandatory
request instantiation between service related Access Points [ACTN- parameter and a number of optional constrains can be specified in
Frame]. Bandwidth is a mandatory parameter and a number of optional the <VN Constrains> (e.g. diversity, cost). They can include
constrains can be specified in the <VN Constrains> (e.g. diversity, objective functions and TE metrics bounds as specified in [RFC5441].
cost). They can include objective functions and TE metrics bounds as
specified in [RFC5441].
Further details on the VN constraints are specified below: Further details on the VN constraints are specified below:
<VN Constraints> ::= [<Layer Protocol>] <VN Constraints> ::= [<Layer Protocol>]
[<Diversity>] [<Diversity>]
[<Shared Risk>] [<Shared Risk>]
( <Metric> | <VN Objective Function> ) ( <Metric> | <VN Objective Function> )
Where: Where:
<Layer Protocol> Identifies the layer topology at which the VN <Layer Protocol> identifies the layer topology at which the VN
service is requested. It could be for example MPLS, ODU, and OCh. service is requested. It could be for example MPLS, ODU, and OCh.
<Diversity> This allows asking for diversity constraints for a VN <Diversity> allows asking for diversity constraints for a VN
Instantiate/Modify or a VN Path Compute. For example, a new VN or Instantiate/Modify or a VN Path Compute. For example, a new VN or
a path is requested in total diversity from an existing one (e.g. a path is requested in total diversity from an existing one (e.g.
diversity exclusion). diversity exclusion).
<Diversity> ::= <VN-exclusion> (<VN-id>...) | <Diversity> ::= (<VN-exclusion> (<VN-id>...)) |
<VN-E2E Tunnel-exclusion> (<Tunnel-id>...) (<VN-Member-exclusion> (<VN-Member-id>...))
<Shared Risk> Based on the realization of VN required, group of <Shared Risk> is used to get the SRLG associated with the
physical resources can be impacted by the same risk. An E2E different tunnels composing a VN. Based on the realization of VN
tunnel can be impacted by this shared risk. This is used to get required, group of physical resources can be impacted by the same
the SRLG associated with the different tunnels composing a VN. risk. VN member (i.e., edge-to-edge link) can be impacted by this
shared risk.
<Metric> can include all the Metrics (cost, delay, delay <Metric> can include all the Metrics (cost, delay, delay
variation, latency), bandwidth utilization parameters defined and variation, latency), bandwidth utilization parameters defined and
referenced by [RFC3630] and [RFC7471]. referenced by [RFC3630] and [RFC7471].
<VN Objective Function> See Section 2.2.4. <VN Objective Function> See Section 5.4.
<VN Survivability> describes all attributes related to the VN <VN Survivability> describes all attributes related to the VN
recovery level and its survivability policy enforced by the recovery level and its survivability policy enforced by the
customers/applications. customers/applications.
<VN Survivability> ::= <VN Recovery Level> <VN Survivability> ::= <VN Recovery Level>
[<VN Tunnel Recovery Level>] [<VN Tunnel Recovery Level>]
[<VN Survivability Policy>] [<VN Survivability Policy>]
Where: Where:
<VN Recovery Level> It is a value representing the requested <VN Recovery Level> is a value representing the requested
level of resiliency required against the VN. The following level of resiliency required against the VN. The following
values are defined: values are defined:
. Unprotected VN . Unprotected VN
. VN with per tunnel recovery: The recovery level is defined . VN with per tunnel recovery: The recovery level is defined
against the tunnels composing the VN and it is specified in against the tunnels composing the VN and it is specified in
the <VN Tunnel Recovery Level>. the <VN Tunnel Recovery Level>.
<VN Tunnel Recovery Level> ::= <0:1>|<1+1>|<1:1>|<1:N>|<M:N>| <VN Tunnel Recovery Level> ::= <0:1>|<1+1>|<1:1>|<1:N>|<M:N>|
skipping to change at page 11, line 28 skipping to change at page 13, line 31
[<Incremental Update>] [<Incremental Update>]
Where: Where:
<Local Reroute Allowed> is a delegation policy to the Server <Local Reroute Allowed> is a delegation policy to the Server
to allow or not a local reroute fix upon a failure of the to allow or not a local reroute fix upon a failure of the
primary LSP. primary LSP.
<Domain Preference> is only applied on the MPI where the MDSC <Domain Preference> is only applied on the MPI where the MDSC
(client) provides a domain preference to each PNC (client) provides a domain preference to each PNC (server),
(server).e.g. when a inter-domain link fails, then PNC can e.g., when an inter-domain link fails, then PNC can choose
choose the alternative peering with this info. the alternative peering with this info.
<Push Allowed> is a policy that allows a server to trigger an <Push Allowed> is a policy that allows a server to trigger an
updated VN topology upon failure without an explicit request updated VN topology upon failure without an explicit request
from the client. Push action can be set as default unless from the client. Push action can be set as default unless
otherwise specified. otherwise specified.
<Incremental Update> is another policy that triggers an <Incremental Update> is another policy that triggers an
incremental update from the server since the last period of incremental update from the server since the last period of
update. Incremental update can be set as default unless update. Incremental update can be set as default unless
otherwise specified. otherwise specified.
2.2.3. VN End-Point 5.3. VN End-Point
<VN End-Point> Object describes the VN's customer end-point <VN End-Point> Object describes the VN's customer end-point
characteristics. characteristics.
<VN End-Point> ::= (<Access Point Identifier> <VN End-Point> ::= (<Access Point Identifier>
[<Access Link Capability>] [<Access Link Capability>]
[<Source Indicator>])... [<Source Indicator>])...
Where: Where:
<Access point identifier> It represents a unique identifier of the <Access point identifier> represents a unique identifier of the
client end-point. They are used by the customer to ask for the client end-point. They are used by the customer to ask for the
setup of a virtual network creation. A <VN End-Point> is defined setup of a virtual network creation. A <VN End-Point> is defined
against each AP in the network and is shared between customer and against each AP in the network and is shared between customer and
provider. Both the customer and the provider will map it against provider. Both the customer and the provider will map it against
his own physical resources. his own physical resources.
<Access Link Capability> An optional object that identifies the <Access Link Capability> identifies the capabilities of the access
capabilities of the access link related to the given access point. link related to the given access point. (e.g., max-bandwidth,
(e.g., max-bandwidth, bandwidth availability, etc.) bandwidth availability, etc.)
<Source Indicator> indicates if an End-point is source or not. <Source Indicator> indicates if an end-point is source or not.
2.2.4. VN Objective Function 5.4. VN Objective Function
The VN Objective Function applies to each VN member (i.e., each E2E The VN Objective Function applies to each VN member (i.e., each E2E
tunnel) of a VN. tunnel) of a VN.
The VN Objective Function can reuse objective functions defined in The VN Objective Function can reuse objective functions defined in
[RFC5541] section 4. [RFC5541] section 4.
For a single path computation, the following objective functions are For a single path computation, the following objective functions are
defined: defined:
skipping to change at page 13, line 5 skipping to change at page 15, line 12
composted by te-link least loaded. composted by te-link least loaded.
o MBP is the Maximum residual Bandwidth Path. o MBP is the Maximum residual Bandwidth Path.
For a concurrent path computation, the following objective functions For a concurrent path computation, the following objective functions
are defined: are defined:
o MBC is to Minimize aggregate Bandwidth Consumption. o MBC is to Minimize aggregate Bandwidth Consumption.
o MLL is to Minimize the Load of the most loaded Link. o MLL is to Minimize the Load of the most loaded Link.
o MCC is to Minimize the Cumulative Cost of a set of paths. o MCC is to Minimize the Cumulative Cost of a set of paths.
2.2.5. VN Action Status 5.5. VN Action Status
<VN Action Status> is the status indicator whether the VN has been <VN Action Status> is the status indicator whether the VN has been
successfully instantiated, modified, or deleted in the server successfully instantiated, modified, or deleted in the server
network or not in response to a particular VN action. network or not in response to a particular VN action.
Note that this action status object can be implicitly indicated and Note that this action status object can be implicitly indicated and
thus not included in any of the VN primitives discussed in Section thus not included in any of the VN primitives discussed in Section
2.3. 2.3.
2.2.6. VN Associated LSP 5.6. VN Topology
<VN Associated LSP> describes the instantiated LSPs that is When a VN is seen by the customer as a topology, it is referred to
associated with the VN. <VN Associated LSP> is used between each as VN topology. This is associated with VN Type 2, which is
domain PNC and the MDSC as part of VN Update once the VN is comprised of virtual nodes virtual and links.
instantiated in each domain network and when CNC want to have more
details about the topology instantiated as consequence of a VN
Instantiate.
<VN Associated LSP> ::= <VN Identifier> (<LSP>...) <VN Topology> ::= <VN node list> <VN link list>
2.2.7. VN Computed Path <VN node list> ::= <VN node> [<VN node list>]
<VN link list> :: = <VN link> [<VN link list>]
5.7. VN Member
<VN Member> describes details of a VN Member which is a list of a set
of VN Members represented as <VN_Member_List>.
<VN_Member_List> ::= <VN Member> [<VN_Member_List>]
Where <VN Member> ::= <Ingress VN End-Point>
[<VN Associated LSP>]
<Egress VN End-Point>
<Ingress VN End-Point> is the VN End-Point information for the
ingress portion of the AP. See Section 5.3 for <VN End-Point>
details.
<Egress VN End-Point> is the VN End-Point information for the egress
portion of the AP. See Section 5.3 for <VN End-Point> details.
<VN Associated LSP> describes the instantiated LSPs in the
Provider's network for the VN Type 1. It describes the instantiated
LSPs over the VN topology for VN Type 2.
5.7.1. VN Computed Path
The VN Computed Path is the list of paths obtained after the VN path The VN Computed Path is the list of paths obtained after the VN path
computation request from higher controller. Note that the computed computation request from higher controller. Note that the computed
path is to be distinguished from the LSP. When the computed path is path is to be distinguished from the LSP. When the computed path is
signaled in the network (and thus the resource is reserved for that signaled in the network (and thus the resource is reserved for that
path), it becomes an LSP. path), it becomes an LSP.
<VN Computed Path> ::= (<Path>...) <VN Computed Path> ::= (<Path>...)
2.2.8. VN Service Preference 5.7.2. VN Service Preference
This section provides VN Service preference. VN Service is defined This section provides VN Service preference. VN Service is defined
in Section 2. in Section 2.
<VN Service Preference> ::= [<Location Service Preference >] <VN Service Preference> ::= [<Location Service Preference >]
[<Client-specific Preference >] [<Client-specific Preference >]
[<End-Point Dynamic Selection Preference >] [<End-Point Dynamic Selection Preference >]
Where Where
<Location Service Preference describes the End-Point Location's <Location Service Preference describes the End-Point Location's
(e.g. Data Centers) support for certain Virtual Network Functions (e.g. Data Centers) support for certain Virtual Network Functions
(VNFs) (e.g., security function, firewall capability, etc.)and is (VNFs) (e.g., security function, firewall capability, etc.) and
used to find the path that satisfies the VNF constraint. is used to find the path that satisfies the VNF constraint.
<Client-specific Preference> describes any preference related to <Client-specific Preference> describes any preference related to
Virtual Network Service (VNS) that application/client can enforce Virtual Network Service (VNS) that application/client can enforce
via CNC towards lower level controllers. For example, permission via CNC towards lower level controllers. For example, permission
the correct selection from the network of the destination related the correct selection from the network of the destination related
to the indicated VNF It is e.g. the case of VM migration among to the indicated VNF It is e.g. the case of VM migration among
data center and CNC can enforce specific policy that can permit data center and CNC can enforce specific policy that can permit
MDSC/PNC to calculate the correct path for the connectivity MDSC/PNC to calculate the correct path for the connectivity
supporting the data center interconnection required by supporting the data center interconnection required by
application. application.
<End-Point Dynamic Selection Preference> describes if the End- <End-Point Dynamic Selection Preference> describes if the End-
Point (e.g. Data Center) can support load balancing, disaster Point (e.g. Data Center) can support load balancing, disaster
recovery or VM migration and so can be part of the selection by recovery or VM migration and so can be part of the selection by
MDSC following service Preference enforcement by CNC. MDSC following service Preference enforcement by CNC.
2.3. Mapping of VN Primitives with VN Objects 6. TE Objects
6.1. TE Tunnel Characteristic
Tunnel Characteristics describes the parameters needed to configure
TE tunnel.
<TE Tunnel Characteristics> ::= [<Tunnel Type>]
<Tunnel Id>
[<Tunnel Layer>]
[<Tunnel end-point>]
[<Tunnel protection-restoration>]
<Tunnel Constraints>
[<Tunnel Optimization>]
Where
<Tunnel Type> ::= <P2P>|<P2MP>|<MP2MP>|<MP2P>
The Tunnel Type identifies the type of required tunnel. In this
draft, only P2P model is provided.
<Tunnel Id> is the TE tunnel identifier
<Tunnel Layer> it represents the layer technology of the LSPs
supporting the tunnel
<Tunnel End Points> ::= <Source> <Destination>
<Tunnel protection-restoration> ::= <prot 0:1>|<prot 1+1>|<prot
1:1>|<prot 1:N>|prot <M:N>|<restoration>
<Tunnel Constraints> are the base tunnel configuration constraints
parameters.
Where <Tunnel Constraints> ::= [<Topology Id>]
[<Bandwidth>]
[<Disjointness>]
[<SRLG>]
[<Priority>]
[<Affinities>]
[<Tunnel Optimization>]
[<Objective Function>]
<Topology Id> references the topology used to compute the tunnel
path.
<Bandwidth> is the bandwidth used as parameter in path computation
<Disjointness> ::= <node> | <link> | <srlg>
<Disjointness> provides the type of resources from which the tunnel
has to be disjointed
<SRLG> is a group of physical resources impacted by the same risk
from which an E2E tunnel is required to be disjointed.
<Priority> ::= <Holding Priority> <Setup Priority>
where
<Setup Priority> indicates the level of priority to taking resources
from another tunnel [RFC 3209]
<Holding Priority> indicates the level of priority to hold resources
avoiding preemption from another tunnel [RFC 3209]
<Affinities> it represent structure to validate link belonging to
path of the tunnel (RFC 3209)
<Tunnel Optimization> ::= <Metric> | <Objective Function>
<Metric> can include all the Metrics (cost, delay, delay variation,
latency), bandwidth utilization parameters defined and referenced by
[RFC3630] and [RFC7471].
<Objective Function> ::= <objective function type>
<objective function type> ::= <MCP> | <MLP> | <MBP> | <MBC> | <MLL>
| <MCC>
See chapter 5.4 for objective function type description.
7. Mapping of VN Primitives with VN Objects
This section describes the mapping of VN Primitives with VN Objects This section describes the mapping of VN Primitives with VN Objects
based on Section 2.2. based on Section 5.
<VN Instantiate> ::= <VN Service Characteristics> <VN Instantiate> ::= <VN Service Characteristics>
<VN End-Point> <VN Member-List>
[<VN Service Preference>] [<VN Service Preference>]
[<VN Topology>]
<VN Modify> ::= <VN identifier> <VN Modify> ::= <VN identifier>
<VN Service Characteristics> <VN Service Characteristics>
<VN End-Point> <VN Member-List>
[<VN Service Preference>] [<VN Service Preference>]
<VN Delete> ::= <VN Identifier> [<VN Topology>]
<VN Delete> ::= <VN Identifier>
<VN Update> :: = <VN Identifier> <VN Update> :: = <VN Identifier>
<VN Associated LSP> [<VN Member-List>]
[<VN Topology>]
<VN Path Compute Request> ::= <VN Service Characteristic> <VN Path Compute Request> ::= <VN Service Characteristic>
<VN End-Point> <VN Member-List>
[<VN Service Preference>]
<VN Path Compute Reply> ::= <VN Computed Path> <VN Path Compute Reply> ::= <VN Computed Path>
<VN Query> ::= <VN Identifier> <VN Query> ::= <VN Identifier>
<VN Query Reply> ::= <VN Identifier> <VN Query Reply> ::= <VN Identifier>
<VN Associated LSP> <VN Associated LSP>
3. References [<TE Topology Reference>]
3.1. Normative References 8. Mapping of TE Primitives with TE Objects
[DRAFT-SER-AWARE] Dhruv Dhody, Qin Wu, Vishwas Manral, Zafar Ali, This section describes the mapping of TE Primitives with TE Objects
and Kenji Kumaki, "Extensions to the Path Computation based on Section 6.
Element Communication Protocol (PCEP) to compute service
aware Label Switched Path (LSP).," June 2016, draft-ietf-
pce-pcep-service-aware-10.
3.2. Informative References <TE Instantiate> ::= <TE Tunnel Characteristics>
[TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", <TE Modify> ::= <TE Tunnel Characteristics>
draft-ietf-teas-yang-te-topo, work in progress.Informative <TE Delete> ::= <Tunnel Id>
References
<TE Update> :: = <Tunnel Id>
<TE Computed Path>
<Path Compute Request> ::= <TE Tunnel Characteristic>
<Path Compute Reply> ::= <TE Computed Path>
<TE Tunnel Characteristics>
9. References
9.1. Normative References
[ACTN-Req] Y. Lee, et al., "Requirements for Abstraction and Control [ACTN-Req] Y. Lee, et al., "Requirements for Abstraction and Control
of Transport Networks", draft-lee-teas-actn-requirements, of Transport Networks", draft-ietf-teas-actn-requirements,
work in progress. work in progress.
[ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and
Control of Transport Networks", draft-ceccarelli-teas- Control of Transport Networks", draft-ietf-teas-actn-
actn-framework, work in progress. framework, work in progress.
[Stateful-PCE] E. Crabbe, et al., "PCEP Extensions for Stateful 9.2. Informative References
PCE", draft-ietf-pce-stateful-pce, work in progress.
[TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies",
draft-ietf-teas-yang-te-topo, work in progress.
[RFC5541] JL. Le Roux, JP. Vasseur and Y. Lee, "Encoding of [RFC5541] JL. Le Roux, JP. Vasseur and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, June 2009. Communication Protocol (PCEP)", RFC 5541, June 2009.
[RFC7926] A.Farrel, et al., "Problem Statement and Architecture for [RFC7926] A. Farrel, et al., "Problem Statement and Architecture for
Information Exchange between Interconnected Traffic- Information Exchange between Interconnected Traffic-
Engineered Networks", RFC 7926, July 2016. Engineered Networks", RFC 7926, July 2016.
4. Contributors [Path-Compute] I. Busi, S. Belotti, et al., "Yang model for
requesting Path Computation", draft-busibel-teas-yang-
path-computation", work in progress.
10. Contributors
Contributors' Addresses Contributors' Addresses
Authors' Addresses Authors' Addresses
Young Lee (Editor) Young Lee (Editor)
Huawei Technologies Huawei Technologies
5340 Legacy Drive 5340 Legacy Drive
Plano, TX 75023, USA Plano, TX 75023, USA
Phone: (469)277-5838 Phone: (469)277-5838
skipping to change at page 17, line 15 skipping to change at page 22, line 48
Divyashree Technopark, Whitefield Divyashree Technopark, Whitefield
Bangalore, India Bangalore, India
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Torshamnsgatan,48 Torshamnsgatan,48
Stockholm, Sweden Stockholm, Sweden
Email: daniele.ceccarelli@ericsson.com Email: daniele.ceccarelli@ericsson.com
Bin Young Yun Bin Yeong Yoon
ETRI ETRI
Email: byyun@etri.re.kr Email: byyun@etri.re.kr
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Appendix A: ACTN Applications
A.1. Coordination of Multi-destination Service Requirement/Policy
+----------------+
| CNC |
| (Global DC |
| Operation |
| Control) |
+--------+-------+
| | Service Requirement/Policy:
| | - Endpoint/DC location info
| | - Endpoint/DC dynamic
| | selection policy
| | (for VM migration, DR, LB)
| v
+---------+---------+
| Multi-domain | Service policy-driven
|Service Coordinator| dynamic DC selection
+-----+---+---+-----+
| | |
| | |
+----------------+ | +----------------+
| | |
+-----+-----+ +-----+------+ +------+-----+
| PNC for | | PNC for | | PNC for |
| Transport | | Transport | | Transport |
| Network A | | Network B | | network C |
+-----------+ +------------+ +------------+
| | |
+---+ ------ ------ ------ +---+
|DC1|--//// \\\\ //// \\\\ //// \\\\---+DC5|
+---+ | | | | | | +---+
| TN A +-----+ TN B +----+ TN C |
/ | | | | |
/ \\\\ //// / \\\\ //// \\\\ ////
+---+ ------ / ------ \ ------ \
|DC2| / \ \+---+
+---+ / \ |DC6|
+---+ \ +---+ +---+
|DC3| \|DC4|
+---+ +---+
DR: Disaster Recovery
LB: Load Balancing
Figure A.1: Service Policy-driven Data Center Selection
Figure A.1 shows how VN service policies from the CNC are
incorporated by the MDSC to support multi-destination applications.
Multi-destination applications refer to applications in which the
selection of the destination of a network path for a given source
needs to be decided dynamically to support such applications.
Data Center selection problems arise for VM mobility, disaster
recovery and load balancing cases. VN's service policy plays an
important role for virtual network operation. Service policy can be
static or dynamic. Dynamic service policy for data center selection
may be placed as a result of utilization of data center resources
supporting VNs. The MDSC would then incorporate this information to
meet the service objective of this application.
A.2. Application Service Policy-aware Network Operation
+----------------+
| CNC |
| (Global DC |
| Operation |
| Control) |
+--------+-------+
| | Application Service Policy
| | - VNF requirement (e.g.
| | security function, etc.)
| | - Location profile for each VNF
| v
+---------+---------+
| Multi-domain | Dynamically select the
|Service Coordinator| network destination to
+-----+---+---+-----+ meet VNF requirement.
| | |
| | |
+---------------+ | +----------------+
| | |
+------+-----+ +-----+------+ +------+-----+
| PNC for | | PNC for | | PNC for |
| Transport | | Transport | | Transport |
| Network A | | Network B | | network C |
| | | | | |
+------------+ +------------+ +------------+
| | |
{VNF b} | | | {VNF b,c}
+---+ ------ ------ ------ +---+
|DC1|--//// \\\\ //// \\\\ //// \\\\-|DC5|
+---+ | | | | | |+---+
| TN A +---+ TN B +--+ TN C |
/ | | | | |
/ \\\\ //// / \\\\ //// \\\\ ////
+---+ ------ / ------ \ ------ \
|DC2| / \ \\+---+
+---+ / \ |DC6|
{VNF a} +---+ +---+ +---+
|DC3| |DC4| {VNF a,b,c}
+---+ +---+
{VNF a, b} {VNF a, c}
Figure A.2: Application Service Policy-aware Network Operation
This scenario is similar to the previous case in that the VN service
policy for the application can be met by a set of multiple
destinations that provide the required virtual network functions
(VNF). Virtual network functions can be, for example, security
functions required by the VN application. The VN service policy by
the CNC would indicate the locations of a certain VNF that can be
fulfilled. This policy information is critical in finding the
optimal network path subject to this constraint. As VNFs can be
dynamically moved across different DCs, this policy should be
dynamically enforced from the CNC to the MDSC and the PNCs.
A.3. Network Function Virtualization Service Enabled Connectivity
+----------------+
| CNC |
| (Global DC |
| Operation |
| Control) |
+--------+-------+
| | Service Policy related to VNF
| | (e.g., firewall, traffic
| | optimizer)
| |
| v
+---------+---------+
| Multi-domain | Select network
|Service Coordinator| connectivity subject to
+-----+---+---+-----+ meeting service policy
| | |
| | |
+---------------+ | +----------------+
| | |
+------+-----+ +-----+------+ +------+-----+
| PNC for | | PNC for | | PNC for |
| Transport | | Transport | | Transport |
| Network A | | Network B | | network C |
| | | | | |
+------------+ +------------+ +------------+
| | |
| | |
+---+ ------ ------ ------ +---+
|DC1|--//// \\\\ //// \\\\ //// \\\\-|DC5|
+---+ | | | | | |+---+
| TN A +---+ TN B +--+ TN C |
/ | | | | |
/ \\\\ //// / \\\\ //// \\\\ ////
+---+ ------ / ------ \ ------ \
|DC2| / \ \\+---+
+---+ / \ |DC6|
+---+ +---+ +---+
|DC3| |DC4|
+---+ +---+
Figure A.3: Network Function Virtualization Service Enabled
Connectivity
Network Function Virtualization Services are usually setup between
customers' premises and service provider premises and are provided
mostly by cloud providers or content delivery providers. The context
may include, but not limited to a security function like firewall, a
traffic optimizer, the provisioning of storage or computation
capacity where the customer does not care whether the service is
implemented in a given data center or another. The customer has to
provide (and CNC is providing this)the type of VNF he needs and the
policy associated with it (e.g. metric like estimated delay to reach
where VNF is located in the DC). The policy linked to VNF is
requested as part of the VN instantiation. These services may be
hosted virtually by the provider or physically part of the network.
This allows the service provider to hide his own resources (both
network and data centers) and divert customer requests where most
suitable. This is also known as "end points mobility" case and
introduces new concepts of traffic and service provisioning and
resiliency (e.g., Virtual Machine mobility).
A.4. Dynamic Service Control Policy Enforcement for Performance and
Fault Management
+------------------------------------------------+
| Customer Network Controller |
+------------------------------------------------+
1.Traffic| /|\4.Traffic | /|\
Monitor& | | Monitor | | 8.Traffic
Optimize | | Result 5.Service | | modify &
Policy | | modify& | | optimize
\|/ | optimize Req.\|/ | result
+------------------------------------------------+
| Multi-domain Service Coordinator |
+------------------------------------------------+
2. Path | /|\3.Traffic | /|\
Monitor | | Monitor | |7.Path
Request | | Result 6.Path | | modify &
| | modify& | | optimize
\|/ | optimize Req.\|/ | result
+------------------------------------------------+
| Physical Network Controller |
+------------------------------------------------+
Figure A.4: Dynamic Service Control for Performance and Fault
Management
Figure A.4 shows the flow of dynamic service control policy
enforcement for performance and fault management initiated by
customer per VN. The feedback loop and filtering mechanism tailored
for VNs performed by the MDSC differentiates this ACTN scope from
traditional network management paradigm. VN level dynamic OAM data
model is a building block to support this capability.
A.5. E2E VN Survivability and Multi-Layer (Packet-Optical) Coordination
for Protection/Restoration
+----------------+
| Customer |
| Network |
| Controller |
+--------*-------+
* | E2E VN Survivability Req.
* | - VN Protection/Restoration
* v - 1+1, Restoration, etc.
+------*-----+ - End Point (EP) info.
| |
| MDSC | MDSC enforces VN survivability
| | requirement, determining the
| | optimal combination of Packet/
+------*-----+ Optical protection/restoration
* Optical bypass, etc.
*
*
**********************************************
* * * *
+----*-----+ +----*----+ +----*-----+ +----*----+
|PNC for | |PNC for | |PNC for | |PNC for |
|Access N. | |Packet C.| |Optical C.| |Access N.|
+----*-----+ +----*----+ +----*-----+ +---*-----+
* --*--- * *
* /// \\\ * *
--*--- | Packet | * ----*-
/// \\\ | Core +------+------/// \\\
| Access +----\\ /// * | Access |
| Network | ---+-- * | Network | +---+
|\\\ /// | * \\\ ///---+EP6|
| +---+- | | -----* -+---+ +---+
+-+-+ | | +----/// \\\ | |
|EP1| | +--------------+ Optical | | | +---+
+---+ | | Core +------+ +--+EP5|
+-+-+ \\\ /// +---+
|EP2| ------ |
+---+ | |
+--++ ++--+
|EP3| |EP4|
+---+ +---+
Figure A.5: E2E VN Survivability and Multi-layer Coordination for
Protection and Restoration
Figure A.5 shows the need for E2E protection/restoration control
coordination that involves CNC, MDSC and PNCs to meet the VN
survivability requirement. VN survivability requirement and its
policy need to be translated into multi-domain and multi-layer
network protection and restoration scenarios across different
controller types. After an E2E path is setup successfully, the MDSC
has a unique role to enforce policy-based flexible VN survivability
requirement by coordinating all PNC domains.
As seen in Figure A.5, multi-layer (i.e., packet/optical)
coordination is a subset of this E2E protection/restoration control
operation. The MDSC has a role to play in determining an optimal
protection/restoration level based on the customer's VN
survivability requirement. For instance, the MDSC needs to interface
the PNC for packet core as well as the PNC for optical core and
enforce protection/restoration policy as part of the E2E
protection/restoration. Neither the PNC for packet core nor the PNC
for optical core is in a position to be aware of the E2E path and
its protection/restoration situation. This role of the MDSC is
unique for this reason. In some cases, the MDSC will have to
determine and enforce optical bypass to find a feasible reroute path
upon packet core network failure which cannot be resolved the packet
core network itself.
To coordinate this operation, the PNCs will need to update its
domain level abstract topology upon resource changes due to a
network failure or other factors. The MDSC will incorporate all
these update to determine if an alternative E2E reroute path is
necessary or not based on the changes reported from the PNCs. It
will need to update the E2E abstract topology and the affected CN's
VN topology in real-time. This refers to dynamic synchronization of
topology from Physical topology to abstract topology to VN topology.
MDSC will also need to perform the path restoration signaling to the
affected PNCs whenever necessary.
 End of changes. 95 change blocks. 
206 lines changed or deleted 428 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/