Internet DRAFT - draft-lee-teas-actn-abstraction
draft-lee-teas-actn-abstraction
TEAS WG
Young Lee
Internet Draft Dhruv Dhody
Intended status: Informational Huawei
Daniele Ceccarelli
Ericsson
Oscar Gonzalez de Dios
Telefonica
Expires: December 2017
June 5, 2017
Abstraction and Control of TE Networks (ACTN) Abstraction Methods
draft-lee-teas-actn-abstraction-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 5, 2017.
Copyright Notice
Lee, et al. Expires December 5, 2017 [Page 1]
Internet-Draft ACTN Abstraction Methods June 2017
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
Abstraction and Control of Traffic Engineering (TE) Networks(ACTN)
refers to the set of virtual network operations needed to
orchestrate, control and manage large-scale multi-domain TE
networks, so as to facilitate network programmability, automation,
and efficient resource sharing.
As the ACTN architecture considers abstraction as one of the
important building blocks, this document describes a few
alternatives methods of abstraction for both packet and optical
networks. This is an important consideration since the choice of the
abstraction method impacts protocol design and the information it
carries.
Table of Contents
1. Introduction...................................................3
2. Abstraction Factors in ACTN Architecture.......................3
3. Build Method of Grey Topology..................................6
3.1. Automatic generation of abstract topology by configuration6
3.2. On-demand generation of supplementary topology via path
compute request/reply..........................................6
4. Protocol/Data Model Requirements...............................8
4.1. Packet Networks...........................................8
4.2. OTN Networks..............................................8
4.3. WSON Networks.............................................9
5. Acknowledgements..............................................11
6. References....................................................11
Lee, et. al. Expires December 5, 2017 [Page 2]
Internet-Draft ACTN Abstraction Methods June 2017
6.1. Informative References...................................11
7. Contributors..................................................11
Authors' Addresses...............................................12
Appendix A:......................................................12
1. Introduction
Abstraction and Control of TE Networks (ACTN) describes a method for
operating a Traffic Engineered (TE) network (such as an MPLS-TE
network or a layer 1 transport network) to provide connectivity and
virtual network services for customers of the TE network. The
services provided can be tuned to meet the requirements (such as
traffic patterns, quality, and reliability) of the applications
hosted by the customers. More details about ACTN can be found in
Section 2.
Abstraction is defined in [RFC7926] as:
Abstraction is the process of applying policy to the available TE
information within a domain, to produce selective information that
represents the potential ability to connect across the domain.
Thus, abstraction does not necessarily offer all possible
connectivity options, but presents a general view of potential
connectivity according to the policies that determine how the
domain's administrator wants to allow the domain resources to be
used.
Connectivity referred to this document is TE path through a series
of connected domains as used in [RFC7926].
As the ACTN architecture considers abstraction as one of the
important building blocks, this document discusses a few
alternatives for the methods of abstraction for both packet and
optical networks. This is an important consideration since the
choice of the abstraction method impacts protocol design and the
information it carries.
The purpose of this document is to find a common agreement on the
factors and methods of abstraction. These abstraction factors and
methods may in turn impact implementations and protocol design.
2. Abstraction Factors in ACTN Architecture
This section provides abstraction factors in the ACTN architecture.
[ACTN-Frame] describes the architecture model for ACTN including the
entities (Customer Network Controller (CNC), Multi-domain Service
Lee, et. al. Expires December 5, 2017 [Page 3]
Internet-Draft ACTN Abstraction Methods June 2017
Coordinator (MDSC), and Physical Network Controller (PNC) and their
interfaces.
The MDSC oversees the specific aspects of the different domains and
builds a single abstracted end-to-end network topology in order to
coordinate end-to-end path computation and path/service
provisioning. In order for the MDSC to perform its coordination
function, it depends on the coordination with the PNCs which are the
domain-level controllers especially as to what level of domain
network resource abstraction is agreed upon between the MDSC and the
PNCs.
As discussed in [RFC7926], abstraction is tied with policy of the
networks. For instance, per an operational policy, the PNC would not
be allowed to provide any technology specific details (e.g., optical
parameters for WSON) in its update. In such case, the abstraction
level of the update will be in a generic nature. In order for the
MDSC to get technology specific topology information from the PNC, a
request/reply mechanism may be employed.
In some cases, abstraction is also tied with the controller's
capability of abstraction as abstraction involves some rules and
algorithms to be applied to the actual network resource information
(which is also known as network topology).
[TE-Topology] describes YANG models for TE-network abstraction.
[PCEP-LS] describes PCEP Link-state mechanism that also allows for
transport of abstract topology in the context of Hierarchical PCE.
There are factors that may impact the choice of abstraction and
presents a number of abstraction methods. It is important to
understand that abstraction depends on several factors:
- The nature of underlying domain networks: Abstraction depends on
the nature of the underlying domain networks. For instance, packet
networks may have different level of abstraction requirements from
that of optical networks. Within optical networks, WSON may have
different level of abstraction requirements than the OTN networks.
- The capability of the PNC: Abstraction depends on the capability
of the PNCs. As abstraction requires hiding details of the
underlying resource network resource information, the PNC
capability to run some internal optimization algorithm impacts the
feasibility of abstraction. Some PNC may not have the ability to
abstract native topology while other PNCs may have such an ability
to abstract actual topology by using sophisticated algorithms.
Lee, et. al. Expires December 5, 2017 [Page 4]
Internet-Draft ACTN Abstraction Methods June 2017
- Scalability factor: Abstraction is a function of scalability. If
the actual network resource information is of small size, then the
need for abstraction would be less than the case where the native
network resource information is of large size. In some cases,
abstraction may not be needed at all.
- The frequency of topology updates: The proper abstraction level
may depend on the frequency of topology updates and vice versa.
- The capability/nature of the MDSC: The nature of the MDSC impacts
the degree/level of abstraction. If the MDSC is not capable of
handling optical parameters such as those specific to OTN/WSON,
then white topology abstraction may not work well.
- The confidentiality: In some cases where the PNC would like to
hide key internal topological data from the MDSC, the abstraction
method should consider this aspect.
- The scope of abstraction: All of the aforementioned factors are
equally applicable to both the MPI (MDSC-PNC Interface) and the
CMI (CNC-MDSC Interface).
[ACTN-Framework] defined the following three levels of topology
abstraction and their descriptions:
. White topology: this is a case where the PNC provides the
actual network topology to the MDSC without any hiding or
filtering.
. Black topology: the entire domain network is abstracted as a
single virtual node (see the definition of virtual node in
[RFC7926]) with the access/egress links without disclosing any
node internal connectivity information.
. Grey topology: this abstraction level is between black topology
and white topology from a granularity point of view. we may
further differentiate from a perspective of how to abstract
internal TE resources between the pairs of border nodes:
o Grey topology type A: border nodes with a TE links between
them in a full mesh fashion
o Grey topology type B: border nodes with some internal
abstracted nodes and abstracted links
Lee, et. al. Expires December 5, 2017 [Page 5]
Internet-Draft ACTN Abstraction Methods June 2017
3. Build Method of Grey Topology
This section discusses two different methods of building a grey
topology:
. Automatic generation of abstract topology by configuration
(Section 3.1)
. On-demand generation of supplementary topology via path
computation request/reply (Section 3.2)
3.1. Automatic generation of abstract topology by configuration
The "Automatic generation" method is based on the
abstraction/summarization of the whole domain by the PNC and its
advertisement on MPI interface once the abstraction level is
configured. The level of abstraction advertisement can be decided
based on some PNC configuration parameters (e.g. provide the
potential connectivity between any PE and any ASBR in an MPLS-TE
network as described in section 3.3.1)
Note that the configuration parameters for this potential topology
can include available B/W, latency, or any combination of defined
parameters. How to generate such tunnel information is beyond the
scope of this document. Appendix A provides one example of this
method for the WSON case.
Such potential topology needs to be periodically or
incrementally/asynchronously updated every time that a failure, a
recovery or the setup of new VNs causes a change in the
characteristics of the advertised grey topology (e.g. in our
previous case if due to changes in the network is it now possible to
provide connectivity between a given PE and a given ASBR with a
higher delay in the update).
3.2. On-demand generation of supplementary topology via path compute
request/reply
The "on-demand generation" of supplementary topology is to be
distinguished from automatic generation of abstract topology. While
abstract topology is generated and updated automatically by
configuration as explained in Section 3.1., additional supplementary
topology may be obtained by the MDSC via path compute request/reply
mechanism. Starting with a black topology advertisement from the
Lee, et. al. Expires December 5, 2017 [Page 6]
Internet-Draft ACTN Abstraction Methods June 2017
PNCs, the MDSC may need additional information beyond the level of
black topology from the PNCs. It is assumed that the black topology
advertisement from PNCs would give the MDSC each domain's the border
node/link information as described in Figure 2. Under this scenario,
when the MDSC needs to allocate a new VN, the MDSC can issue a
number of Path Computation requests as described in [ACTN-YANG] to
different PNCs with constraints matching the VN request.
An example is provided in Figure 4, where the MDSC is requesting to
setup a P2P VN between AP1 and AP2. The MDSC can use two different
inter-domain links to get from Domain X to Domain Y, namely the one
between ASBRX.1 and ASBRY.1 and the one between ASBRX.2 and ASBRY.2,
but in order to choose the best end to end path it needs to know
what domain X and Y can offer in term of connectivity and
constraints between the PE nodes and the ASBR nodes.
------- -------
( ) ( )
- ASBRX.1------- ASBRY.1 -
(+---+ ) ( +---+)
-+---( |PE1| Dom.X ) ( Dom.Y |PE2| )---+-
| (+---+ ) ( +---+) |
AP1 - ASBRX.2------- ASBRY.2 - AP2
( ) ( )
------- -------
Figure 4: A multi-domain networks example
A path computation request will be issued to PNC.X asking for
potential connectivity between PE1 and ASBRX.1 and between PE1 and
ASBRX.2 with related objective functions and TE metric constraints.
A similar request will be issued to PNC.Y and the results merged
together at the MDSC to be able to compute the optimal end-to-end
path including the inter domain links.
The info related to the potential connectivity may be cached by the
MDSC for subsequent path computation processes or discarded, but in
this case the PNCs are not requested to keep the grey topology
updated.
Lee, et. al. Expires December 5, 2017 [Page 7]
Internet-Draft ACTN Abstraction Methods June 2017
4. Protocol/Data Model Requirements
This section provides a set of requirements that may impact the way
protocol/data model is designed and the information elements thereof
which are carried in the protocol/data model.
It is expected that the abstraction level be negotiated between the
CNC and the MDSC (i.e., the CMI) depending on the capability of the
CNC. This negotiated level of abstraction on the CMI may also impact
the way the MDSC and the PNCs configure and encode the abstracted
topology. For example, if the CNC is capable of sophisticated
technology specific operation, then this would impact the level of
abstraction at the MDSC with the PNCs. On the other hand, if the CNC
asks for a generic topology abstraction, then the level of
abstraction at the MDSC with the PNCs can be less technology
specific than the former case.
The subsequent sections provide a list of possible abstraction
levels for various technology domain networks.
4.1. Packet Networks
- For grey abstraction, the type of abstraction and its parameters
MUST be defined and configured/negotiated.
o Abstraction Level 1: TE-tunnel abstraction for all (S-D)
border pairs with:
. Maximum B/W available per Priority Level
. Minimum Latency
o Other Level (TBD)
4.2. OTN Networks
For OTN networks, max bandwidth available may be per ODU 0/1/2/3
switching level or aggregated across all ODU switching levels (i.e.,
ODUj/k).Clearly, there is a trade-off between these two abstraction
methods. Some OTN switches can switch any level of ODUs and in such
case there is no need for ODU level abstraction.
- For grey abstraction, the type of abstraction and its parameters
MUST be defined and configured/negotiated.
o Abstraction Level 1: Per ODU Switching level (i.e., ODU type
and number) TE-tunnel abstraction for all (S-D) border pairs
with:
Lee, et. al. Expires December 5, 2017 [Page 8]
Internet-Draft ACTN Abstraction Methods June 2017
. Maximum B/W available per Priority Level
. Minimum Latency
o Abstraction Level 2: Aggregated TE-tunnel abstraction for all
(S-D) border pairs with:
. Maximum B/W available per Priority Level
. Minimum Latency
o Other Level (TBD)
4.3. WSON Networks
For WSON networks, max bandwidth available may be per
lambda/frequency level (OCh) or aggregated across all
lambda/frequency level. Per OCh level abstraction gives more
detailed data to the MDSC at the expense of more information
processing. Either OCh-level or aggregated level abstraction should
factor in the RWA constraint (i.e., wavelength continuity) at the
PNC level. This means the PNC should have this capability and
advertise it as such. See the Appendix for this abstraction method.
- For grey abstraction, the type of abstraction MUST and its
parameters be defined and configured/negotiated.
o Abstraction Level 1: Per Lambda/Frequency level TE-tunnel
abstraction for all (S-D) border pairs with:
. Maximum B/W available per Priority Level
. Minimum Latency
o Abstraction Level 2: Aggregated TE-tunnel abstraction for all
(S-D) border pairs with:
. Maximum B/W available per Priority Level
. Minimum Latency
o Other Level (TBD)
Examples: these examples show how to compute WSON grey topology
Abstraction Level 1 and Level 2. These examples illustrate that the
encoding of an abstraction topology can be impacted by the
configured/negotiated abstraction level in the ACTN interfaces.
This section provides how WSON grey topology abstraction levels 1
and 2 can be computed at a PNC. These examples illustrate that the
Lee, et. al. Expires December 5, 2017 [Page 9]
Internet-Draft ACTN Abstraction Methods June 2017
encoding of an abstraction topology can be impacted by the
configured/negotiated abstraction level at the MPI.
. Abstraction Level 1: Per Lambda/Frequency level TE-tunnel
abstraction for all (S-D) border pairs:
For each (S-D) border node pair,
1) The concept of a lambda plane: A lambda plane is a confined
optical topology with respect to a given lambda value. If an OMS
link has the wavelength of the given lambda available, it is
included, otherwise excluded.
2) Calculate the maximal flow between S and D in every lambda plane.
Max flow computation is restricted to each lambda plane is for OCh
wavelength continuity.
3) Convert each feasible lambda plane with OCh wavelength continuity
to B/W equivalent encoding; Send this per lambda level encoding
for (S-D) to the MDSC;
. Abstraction Level 2: Aggregated TE-tunnel abstraction for WSON
for all (S-D) border pairs
For each (S-D) border node pair,
1) The concept of a lambda plane: A lambda plane is a confined
optical topology with respect to a given lambda value. If an OMS
link has the wavelength of the given lambda available, it is
included, otherwise excluded.
2) Calculate the maximal flow between S and D in every lambda plane.
Max flow computation is restricted to each lambda plane is for OCh
wavelength continuity.
3) Add up the max flow values across all lambda planes. This is the
maximal number of OCh paths that can be setup between S and D at
the same time.
4) Convert the max number of OCh paths to B/W equivalent encoding;
Send this encoding as max B/W for (S-D) to the MDSC;
Lee, et. al. Expires December 5, 2017 [Page 10]
Internet-Draft ACTN Abstraction Methods June 2017
5. Acknowledgements
We thank Adrian Farrel and Italo Busi for providing useful comments
and suggestions for this draft.
6. References
6.1. Informative References
[RFC7926] A. Farrel, Ed., "Problem Statement and Architecture for
Information Exchange between Interconnected Traffic-
Engineered Networks", RFC 7926, July 2016.
[ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and
Control of Traffic Engineered Networks", draft-ietf-teas-
actn-framework, work in progress.
[TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies",
draft-ietf-teas-yang-te-topo, work in progress.
[PCEP-LS] D. Dhody, Y. Lee and D. Ceccarelli, "PCEP Extension for
Distribution of Link-State and TE Information," draft-
dhodylee-pce-pcep-ls, work in progress.
[RFC7926] A. Farrel, et. al., "Problem Statement and Architecture
for Information Exchange Between Interconnected Traffic
Engineered Networks", RFC 7926, July 2016.
[ACTN-YANG] X. Zhang, et. Al., "Applicability of YANG models for
Abstraction and Control of Traffic Engineered Networks",
draft-zhang-teas-actn-yang, work in progress
7. Contributors
Contributor's Addresses
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Xian Zhang
Huawei
Email: zhang.xian@huawei.com
Lee, et. al. Expires December 5, 2017 [Page 11]
Internet-Draft ACTN Abstraction Methods June 2017
Authors' Addresses
Young Lee
Huawei Technologies
5340 Legacy Drive
Plano, TX 75023, USA
Phone: (469)277-5838
Email: leeyoung@huawei.com
Dhruv Dhody
Huawei Technologies
Email: dhruv.ietf@gmail.com
Daniele Ceccarelli
Ericsson
Torshamnsgatan,48
Stockholm, Sweden
Email: daniele.ceccarelli@ericsson.com
Oscar Gonzalez de Dios
Telefonica
Email: oscar.gonzalezdedios@telefonica.com
Lee, et. al. Expires December 5, 2017 [Page 12]
