< draft-ietf-teas-actn-info-model-07.txt   draft-ietf-teas-actn-info-model-08.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: August 5, 2018 Expires: November 1, 2018
Dhruv Dhody Dhruv Dhody
Huawei Huawei
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Bin Yeong Yoon Bin Yeong Yoon
ETRI ETRI
February 5, 2018 May 1, 2018
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-07.txt draft-ietf-teas-actn-info-model-08.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 Networks (ACTN). of Traffic Engineered 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 August 5, 2018. This Internet-Draft will expire on November 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
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
3. Virtual Network primitives.....................................5 3. Virtual Network primitives.....................................5
3.1. VN Instantiate............................................6 3.1. VN Instantiate............................................6
3.2. VN Modify.................................................7 3.2. VN Modify.................................................7
3.3. VN Delete.................................................7 3.3. VN Delete.................................................7
3.4. VN Update.................................................7 3.4. VN Update.................................................7
3.5. VN Compute................................................7 3.5. VN Compute................................................7
3.6. VN Query..................................................8
4. Traffic Engineering (TE) primitives............................8 4. Traffic Engineering (TE) primitives............................8
4.1. TE Instantiate............................................9 4.1. TE Instantiate............................................9
4.2. TE Modify.................................................9 4.2. TE Modify.................................................9
4.3. TE Delete.................................................9 4.3. TE Delete.................................................9
4.4. TE Topology Update (for TE resources).....................9 4.4. TE Topology Update (for TE resources).....................9
4.5. Path Compute.............................................10 4.5. Path Compute.............................................10
5. VN Objects....................................................10 5. VN Objects....................................................10
5.1. VN Identifier............................................10 5.1. VN Identifier............................................10
5.2. VN Service Characteristics...............................10 5.2. VN Service Characteristics...............................11
5.3. VN End-Point.............................................13 5.3. VN End-Point.............................................13
5.4. VN Objective Function....................................14 5.4. VN Objective Function....................................14
5.5. VN Action Status.........................................14 5.5. VN Action Status.........................................15
5.6. VN Topology..............................................15 5.6. VN Topology..............................................15
5.7. VN Member................................................15 5.7. VN Member................................................15
5.7.1. VN Computed Path....................................16 5.7.1. VN Computed Path....................................16
5.7.2. VN Service Preference...............................16 5.7.2. VN Service Preference...............................16
6. TE Objects....................................................17 6. TE Objects....................................................17
6.1. TE Tunnel Characteristic.................................17 6.1. TE Tunnel Characteristic.................................17
7. Mapping of VN Primitives with VN Objects......................19 7. Mapping of VN primitives with VN Objects......................19
8. Mapping of TE Primitives with TE Objects......................20 8. Mapping of TE primitives with TE Objects......................20
9. Security Considerations.......................................21 9. Security Considerations.......................................21
10. IANA Considerations..........................................22 10. IANA Considerations..........................................22
11. References...................................................22 11. References...................................................22
11.1. Normative References....................................22 11.1. Normative References....................................22
11.2. Informative References..................................22 11.2. Informative References..................................22
12. Contributors.................................................23 12. Contributors.................................................23
Contributors' Addresses..........................................23 Contributors' Addresses..........................................23
Authors' Addresses...............................................23 Authors' Addresses...............................................23
1. Introduction 1. Introduction
skipping to change at page 4, line 26 skipping to change at page 4, line 26
/ | \ / | \
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| 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. This document Interface) and MPI (MDSC-PNC Interface), respectively. This document
models these two interfaces and derivative interfaces there of models these two interfaces and derivative interfaces thereof
(e.g., MDSC to MSDC in a hierarchy of MDSCs) as a single common (e.g., MDSC to MDSC in a hierarchy of MDSCs) as a single common
interface. interface.
1.1. Terminology 1.1. Terminology
The terms "Virtual Network (VN)" and "Virtual Network Service (VNS)" The terms "Virtual Network (VN)" and "Virtual Network Service (VNS)"
are defined in [ACTN-Frame] and the terms "abstraction" and are defined in [ACTN-Frame] and the terms "abstraction" and
"abstract topology" are defined in [RFC7926]. "abstract topology" are defined in [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 an 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
for the service applications needed in the ACTN context. for the service applications needed in the ACTN context.
The standard interface is described between a client controller and The standard interface is described between a client controller and
a server controller. A client-server relationship is recursive a server controller. A client-server relationship is recursive
between a CNC and an MDSC and between an MDSC and a PNC. In the CMI, between a CNC and an MDSC and between an MDSC and a PNC. In the CMI,
the client is a CNC while the server is an MDSC. In the MPI, the the client is a CNC while the server is an MDSC. In the MPI, the
client is an MDSC and the server is a PNC. There may also be MDSC- client is an MDSC and the server is a PNC. There may also be MDSC-
MDSC interface(s) that need to be supported. This may arise in a MDSC interface(s) that need to be supported. This may arise in a
skipping to change at page 6, line 4 skipping to change at page 5, line 49
- The second type is referred to as TE topology which is - The second type is referred to as TE topology which is
associated with provider network operation on which we can associated with provider network operation on which we can
apply policy to obtain the required level of abstraction to apply policy to obtain the required level of abstraction to
represent the underlying physical network topology. represent the underlying physical network topology.
3. Virtual Network primitives 3. Virtual Network primitives
This section provides a list of main VN primitives related to This section provides a list of main VN primitives related to
virtual network which are necessary to satisfy ACTN requirements virtual network which are necessary to satisfy ACTN requirements
specified in [ACTN-REQ] specified in [ACTN-REQ]
At a minimum, the following VN Action primitives should be
supported: The following VN Action primitives are supported:
- VN Instantiate - VN Instantiate
- VN Modify - VN Modify
- VN Delete - VN Delete
- VN Update - VN Update
- VN Path Compute - VN Path Compute
skipping to change at page 7, line 12 skipping to change at page 7, line 10
VN type 2: VN is viewed as a VN-topology comprising virtual nodes VN type 2: VN is viewed as a VN-topology comprising virtual nodes
and virtual links. and virtual links.
Please see [ACTN-Frame] for full details regarding the types of VN. Please see [ACTN-Frame] for full details regarding the types of VN.
3.2. VN Modify 3.2. VN Modify
VN Modify refers to an action issued from customers/applications to VN Modify refers to an action issued from customers/applications to
modify an existing VN (i.e., an instantiated VN). modify an existing VN (i.e., an instantiated VN).
VN Modify, depending of the type of VN instantiated, can be a
modification of the characteristics of VN members (edge-to-edge
links) in case of VN type 1, or a modification of an existing
virtual topology (e.g., adding/deleting virtual nodes/links) in case
of VN type 2.
3.3. VN Delete 3.3. VN Delete
VN Delete refers to an action issued from customers/applications to VN Delete refers to an action issued from customers/applications to
delete an existing VN. delete an existing VN.
3.4. VN Update 3.4. VN Update
VN Update refers to any update to the VN that needs to be updated to 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 the customers. VN Update fulfills a push model at CMI level, to make
customers aware of any specific changes in the topology details customers aware of any specific changes in the topology details
skipping to change at page 8, line 10 skipping to change at page 8, line 12
VN Compute Request/Reply is to be differentiated from a VN VN Compute Request/Reply is to be differentiated from a VN
Instantiate. The purpose of VN Compute is a priori exploration to Instantiate. The purpose of VN Compute is a priori exploration to
compute network resources availability and getting a possible VN compute network resources availability and getting a possible VN
view in which path details can be specified matching view in which path details can be specified matching
customer/applications constraints. This a priori exploration may not customer/applications constraints. This a priori exploration may not
guarantee the availability of the computed network resources at the guarantee the availability of the computed network resources at the
time of instantiation. time of instantiation.
3.6. VN Query 3.6. VN Query
VN Query refers to inquiry pertaining to the VN that has been VN Query refers to an inquiry pertaining to a VN that has already
already instantiated. VN Query fulfills a pull model and permit to been instantiated. VN Query fulfills a pull model that permits
get topology view. getting a 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. The
topology view returned by VN Query Reply would be consistent with
the topology type instantiated for any specific VN.
4. Traffic Engineering (TE) primitives 4. Traffic Engineering (TE) primitives
This section provides a list of main TE primitives necessary to This section provides a list of the main TE primitives necessary to
satisfy ACTN requirements specified in [ACTN-REQ] related to typical satisfy ACTN requirements specified in [ACTN-REQ] related to typical
TE operations supported at MPI level. TE operations supported at the MPI level.
At a minimum, the following TE action primitives should be The TE action primitives defined in this section should be supported
supported: at the MPI consistently with the type of topology defined at the
CMI.
The following TE action primitives are supported:
- TE Instantiate/Modify/Delete - TE Instantiate/Modify/Delete
- TE Topology Update (See Section 4.4. for the description) - TE Topology Update (See Section 4.4. for the description)
- Path Compute - Path Compute
TE Action is an object describing the main TE primitives. TE Action is an object describing the main TE primitives.
TE Action can assume one of the mentioned above primitives values. TE Action can assume one of the mentioned above primitives values.
skipping to change at page 11, line 7 skipping to change at page 11, line 12
VN Identifier is a unique identifier of the VN. VN Identifier is a unique identifier of the VN.
5.2. VN Service Characteristics 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 Directionality>
(<VN Traffic Matrix>...) (<VN Traffic Matrix>...)
<VN Survivability> <VN Survivability>
Where Where
<VN Connectivity Type> ::= <P2P>|<P2MP>|<MP2MP>|<MP2P>|<Multi- <VN Connectivity Type> ::= <P2P>|<P2MP>|<MP2MP>|<MP2P>|<Multi-
destination> destination>
The Connectivity Type identifies the type of required VN Service. In The Connectivity Type identifies the type of required VN Service. In
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 Directionality indicates if a VN is unidirectional or
bidirectional. This implies that each VN member that belongs to the
VN has the same directionality as the VN.
<VN Traffic Matrix> ::= <Bandwidth> <VN Traffic Matrix> ::= <Bandwidth>
[<VN Constraints>] [<VN Constraints>]
The VN Traffic Matrix represents the traffic matrix parameters for The VN Traffic Matrix represents the traffic matrix parameters for
the required the service connectivity. Bandwidth is a mandatory the required service connectivity. Bandwidth is a mandatory
parameter and a number of optional constrains can be specified in parameter and a number of optional constraints can be specified in
the VN Constrains (e.g. diversity, cost). They can include objective the VN Constraints (e.g. diversity, cost). They can include
functions and TE metrics bounds as specified in [RFC5541]. objective functions and TE metrics bounds as specified in [RFC5541].
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>]
( <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 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-Member-exclusion> (<VN-Member-id>...)) (<VN-Member-exclusion> (<VN-Member-id>...))
Shared Risk is used to get the SRLG associated with the different
tunnels composing a VN. Based on the realization of VN required,
group of physical resources can be impacted by the same 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 variation, Metric can include all the Metrics (cost, delay, delay variation,
latency), bandwidth utilization parameters defined and referenced latency), bandwidth utilization parameters defined and referenced
by [RFC3630] and [RFC7471]. by [RFC3630] and [RFC7471].
As for VN Objective Function See Section 5.4. As for VN Objective Function See Section 5.4.
VN Survivability describes all attributes related to the VN recovery VN Survivability describes all attributes related to the VN recovery
level and its survivability policy enforced by the level and its survivability policy enforced by the
customers/applications. customers/applications.
skipping to change at page 13, line 45 skipping to change at page 14, line 7
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 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 instantiation. A VN End-Point is
against each AP in the network and is shared between customer and defined against each AP in the network and is shared between
provider. Both the customer and the provider will map it against customer and provider. Both the customer and the provider will map
his own physical resources. it against their own physical resources.
Access Link Capability identifies the capabilities of the access Access Link Capability identifies the capabilities of the access
link related to the given access point. (e.g., max-bandwidth, link related to the given access point. (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.
5.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
skipping to change at page 15, line 12 skipping to change at page 15, line 18
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
3. 3.
5.6. VN Topology 5.6. VN Topology
When a VN is seen by the customer as a topology, it is referred to When a VN is seen by the customer as a topology, it is referred to
as VN topology. This is associated with VN Type 2, which is as VN topology. This is associated with VN Type 2, which is composed
comprised of virtual nodes virtual and links. of virtual nodes and virtual links.
<VN Topology> ::= <VN node list> <VN link list> <VN Topology> ::= <VN node list> <VN link list>
<VN node list> ::= <VN node> [<VN node list>] <VN node list> ::= <VN node> [<VN node list>]
<VN link list> :: = <VN link> [<VN link list>] <VN link list> :: = <VN link> [<VN link list>]
5.7. VN Member 5.7. VN Member
VN Member describes details of a VN Member which is a list of a set VN Member describes details of a VN Member which is a list of a set
skipping to change at page 16, line 8 skipping to change at page 16, line 12
Egress VN End-Point is the VN End-Point information for the egress 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. portion of the AP. See Section 5.3 for VN End-Point details.
VN Associated LSP describes the instantiated LSPs in the Provider's VN Associated LSP describes the instantiated LSPs in the Provider's
network for the VN Type 1. It describes the instantiated LSPs over network for the VN Type 1. It describes the instantiated LSPs over
the VN topology for VN Type 2. the VN topology for VN Type 2.
5.7.1. VN Computed Path 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 a 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>...)
5.7.2. 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.
skipping to change at page 18, line 15 skipping to change at page 18, line 21
[<Disjointness>] [<Disjointness>]
[<SRLG>] [<SRLG>]
[<Priority>] [<Priority>]
[<Affinities>] [<Affinities>]
[<Tunnel Optimization>] [<Tunnel Optimization>]
[<Objective Function>]
Topology Id references the topology used to compute the tunnel path. Topology Id references the topology used to compute the tunnel path.
Bandwidth is the bandwidth used as parameter in path computation Bandwidth is the bandwidth used as parameter in path computation
<Disjointness> ::= <node> | <link> | <srlg> <Disjointness> ::= <node> | <link> | <srlg>
Disjointness provides the type of resources from which the tunnel Disjointness provides the type of resources from which the tunnel
has to be disjointed has to be disjointed
SRLG is a group of physical resources impacted by the same risk from SRLG is a group of physical resources impacted by the same risk from
which an E2E tunnel is required to be disjointed. which an E2E tunnel is required to be disjointed.
<Priority> ::= <Holding Priority> <Setup Priority> <Priority> ::= <Holding Priority> <Setup Priority>
where where
Setup Priority indicates the level of priority to taking resources Setup Priority indicates the level of priority for taking resources
from another tunnel [RFC3209] from another tunnel [RFC3209]
Holding Priority indicates the level of priority to hold resources Holding Priority indicates the level of priority to hold resources
avoiding preemption from another tunnel [RFC3209] avoiding preemption from another tunnel [RFC3209]
Affinities represent structure to validate link belonging to path Affinities represent structure to validate link belonging to path
of the tunnel [RFC3209] of the tunnel [RFC3209]
<Tunnel Optimization> ::= <Metric> | <Objective Function> <Tunnel Optimization> ::= <Metric> | <Objective Function>
Metric can include all the Metrics (cost, delay, delay variation, Metric can include all the Metrics (cost, delay, delay variation,
latency), bandwidth utilization parameters defined and referenced by latency), bandwidth utilization parameters defined and referenced by
[RFC3630] and [RFC7471]. [RFC3630] and [RFC7471].
<Objective Function> ::= <objective function type> <Objective Function> ::= <objective function type>
<objective function type> ::= <MCP> | <MLP> | <MBP> | <MBC> | <MLL> <objective function type> ::= <MCP> | <MLP> | <MBP> | <MBC> | <MLL>
| <MCC> | <MCC>
See chapter 5.4 for objective function type description. See chapter 5.4 for objective function type description.
7. Mapping of VN Primitives with VN Objects 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 5. based on Section 5.
<VN Instantiate> ::= <VN Service Characteristics> <VN Instantiate> ::= <VN Service Characteristics>
<VN Member-List> <VN Member-List>
[<VN Service Preference>] [<VN Service Preference>]
[<VN Topology>] [<VN Topology>]
skipping to change at page 20, line 18 skipping to change at page 20, line 25
<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>
[<TE Topology Reference>] [<TE Topology Reference>]
8. Mapping of TE Primitives with TE Objects 8. Mapping of TE primitives with TE Objects
This section describes the mapping of TE Primitives with TE Objects This section describes the mapping of TE primitives with TE Objects
based on Section 6. based on Section 6.
<TE Instantiate> ::= <TE Tunnel Characteristics> <TE Instantiate> ::= <TE Tunnel Characteristics>
<TE Modify> ::= <TE Tunnel Characteristics> <TE Modify> ::= <TE Tunnel Characteristics>
<TE Delete> ::= <Tunnel Id> <TE Delete> ::= <Tunnel Id>
<TE Topology Update> ::= <TE-topology-list>
<TE Topology Update> :: = <TE-topology-list>
<Path Compute Request> ::= <TE Tunnel Characteristics> <Path Compute Request> ::= <TE Tunnel Characteristics>
<Path Compute Reply> ::= <TE Computed Path> <Path Compute Reply> ::= <TE Computed Path>
<TE Tunnel Characteristics> <TE Tunnel Characteristics>
9. Security Considerations 9. Security Considerations
The ACTN information model described in this document defines key The ACTN information model described in this document defines key
interfaces for managed traffic engineered networks. Securing the interfaces for managed traffic engineered networks. Securing the
request and control of resources, confidentially of the information, request and control of resources, confidentiality of the
and availability of function are critical security considerations information, and availability of function, should all be critical
when deploying and operating ACTN platforms. security considerations when deploying and operating ACTN platforms.
Several distributed ACTN functional components are required, and Several distributed ACTN functional components are required, and
implementations should consider encrypting data that flows between implementations should consider encrypting data that flows between
components, especially when they are implemented at remote nodes, components, especially when they are implemented at remote nodes,
regardless these data flows are on external or internal network regardless of these data flows are on external or internal network
interfaces. interfaces.
The ACTN security discussion is further split into two specific
categories described in the following sub-sections:
- Interface between the Customer Network Controller and Multi Domain
Service Coordinator (MDSC), CNC-MDSC Interface (CMI)
- Interface between the Multi Domain Service Coordinator and
Provisioning Network Controller (PNC), MDSC-PNC Interface (MPI)
From a security and reliability perspective, ACTN may encounter many From a security and reliability perspective, ACTN may encounter many
risks such as malicious attack and rogue elements attempting to risks such as malicious attack and rogue elements attempting to
connect to various ACTN components. Furthermore, some ACTN connect to various ACTN components. Furthermore, some ACTN
components represent a single point of failure and threat vector, components represent a single point of failure and threat vector,
and must also manage policy conflicts, and eavesdropping of and must also manage policy conflicts, and eavesdropping of
communication between different ACTN components. communication between different ACTN components.
The conclusion is that all data models and protocols used to realize The conclusion is that all data models and protocols used to realize
the ACTN info model should have rich security features, and the ACTN info model should have rich security features, and
customer, application and network data should be stored in encrypted customer, application and network data should be stored in encrypted
skipping to change at page 22, line 17 skipping to change at page 22, line 25
This document has no actions for IANA. This document has no actions for IANA.
11. References 11. References
11.1. Normative References 11.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-ietf-teas-actn-requirements, of Transport Networks", draft-ietf-teas-actn-requirements,
work in progress. work in progress.
[ACTN-Frame] D. Ceccarelli and Y. Lee, "Framework for Abstraction [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and
and Control of Transport Networks, draft-ietf-teas-actn- Control of Transport Networks", draft-ietf-teas-actn-
framework, work in progress. framework, work in progress.
11.2. Informative References 11.2. Informative References
[TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies",
draft-ietf-teas-yang-te-topo, work in progress. draft-ietf-teas-yang-te-topo, work in progress.
[RFC3209] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP [RFC3209] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
 End of changes. 41 change blocks. 
55 lines changed or deleted 77 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/