Skip to main content

Abstraction and Control of TE Networks (ACTN) Abstraction Methods
draft-lee-teas-actn-abstraction-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Young Lee , Dhruv Dhody , Daniele Ceccarelli , Oscar Gonzalez de Dios
Last updated 2017-03-13
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-lee-teas-actn-abstraction-01
TEAS WG
                                                              Young Lee
Internet Draft                                              Dhruv Dhody
Intended status: Informational                                    Huawei

                                                     Daniele Ceccarelli
                                                               Ericsson

                                                 Oscar Gonzalez de Dios
                                                             Telefonica

Expires: September 2017

                                                         March 13, 2017

   Abstraction and Control of TE Networks (ACTN) Abstraction Methods

                   draft-lee-teas-actn-abstraction-01

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 September 13, 2017.

Copyright Notice

Lee, et al.           Expires September 13, 2017               [Page 1]
Internet-Draft         ACTN Abstraction Methods              March 2017

   Copyright (c) 2016 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. ACTN Architecture..............................................4
   3. Abstraction Factors and Methods................................5
      3.1. No abstraction (native/white topology)....................6
      3.2. One Abstract Node (black topology)........................7
      3.3. Abstraction of TE tunnels for all pairs of border nodes
      (grey topology)................................................9
         3.3.1. Grey topology type A: border nodes with a TE links
         between them in a full mesh fashion........................10
         3.3.2. Grey topology Type B................................11
      3.4. How to build grey topology...............................11

Lee, et. al.          Expires September 13, 2017               [Page 2]
Internet-Draft         ACTN Abstraction Methods              March 2017

         3.4.1. Automatic generation of abstract topology by
         configuration..............................................11
         3.4.2. On-demand generation of supplementary topology via path
         compute request/reply......................................12
   4. Protocol/Data Model Requirements..............................13
      4.1. Packet Networks..........................................13
      4.2. OTN Networks.............................................14
      4.3. WSON Networks............................................14
   5. Security......................................................14
   6. Acknowledgements..............................................15
   7. References....................................................15
      7.1. Informative References...................................15
   8. Contributors..................................................15
   Authors' Addresses...............................................16
   Appendix A:......................................................16

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.

Lee, et. al.          Expires September 13, 2017               [Page 3]
Internet-Draft         ACTN Abstraction Methods              March 2017

   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. ACTN Architecture

   This section provides a brief description of ACTN architecture.
   [ACTN-Frame] describes the architecture model for ACTN including the
   entities (Customer Network Controller (CNC), Multi-domain Service
   Coordinator (MDSC), and Physical Network Controller (PNC) and their
   interfaces.

   Figure 1 depicts a high-level control and interface architecture for
   ACTN and is a reproduction of Figure 5 from [ACTN-Frame].

   VPN customer         NW Mobile Customer     ISP NW service Customer
       |                         |                           |
   +-------+                 +-------+                   +-------+
   | CNC-A |                 | CNC-B |                   | CNC-C |
   +-------+                 +-------+                   +-------+
        \                        |                           /
          -----------            |CMI I/F      --------------
                     \           |            /
                      +-----------------------+
                      |         MDSC          |
                      +-----------------------+
                      /          |            \
         -------------           |MPI I/F      -------------
        /                        |                          \
   +-------+                 +-------+                   +-------+
   |  PNC  |                 |  PNC  |                   |  PNC  |
   +-------+                 +-------+                   +-------+
        | GMPLS             /      |                      /    \
        | trigger          /       |                     /      \
       --------         ----      +-----+            +-----+     \
      (        )       (    )     | PNC |            | PCE |      \
      -        -      ( Phys )    +-----+            +-----+    -----
     (  GMPLS   )      (Netw)        |                /        (     )
    (  Physical  )      ----         |               /        ( Phys. )
     (  Network )                 -----        -----           ( Net )
      -        -                 (     )      (     )           -----
      (        )                ( Phys. )    ( Phys  )
       --------                  ( Net )      ( Net )
                                  -----        -----

                     Figure 1 : ACTN Control Hierarchy

Lee, et. al.          Expires September 13, 2017               [Page 4]
Internet-Draft         ACTN Abstraction Methods              March 2017

   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.

3. Abstraction Factors and Methods

   This section discusses 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

Lee, et. al.          Expires September 13, 2017               [Page 5]
Internet-Draft         ACTN Abstraction Methods              March 2017

     abstract native topology while other PNCs may have such an ability
     to abstract actual topology by using sophisticated algorithms.

   - Scalability factor: Abstraction is a function of scalability. If
     the actual network resource information is of small size, then the
     need for abstraction would be less than the case where the native
     network resource information is of large size. In some cases,
     abstraction may not be needed at all.

   - The frequency of topology updates: The proper abstraction level
     may depend on the frequency of topology updates and vice versa.

   - The capability/nature of the MDSC: The nature of the MDSC impacts
     the degree/level of abstraction. If the MDSC is not capable of
     handling optical parameters such as those specific to OTN/WSON,
     then white topology abstraction may not work well.

   - The confidentiality:  In some cases where the PNC would like to
     hide key internal topological data from the MDSC, the abstraction
     method should consider this aspect.

   - The scope of abstraction: All of the aforementioned factors are
     equally applicable to both the MPI (MDSC-PNC Interface) and the
     CMI (CNC-MDSC Interface).

   With having the aforementioned factors in mind, the following
   abstraction methods can be considered for implementations.

3.1. No abstraction (native/white topology)

   This is a case where the PNC provides the actual network topology to
   the MDSC without any hiding or filtering. In this case, the MDSC has
   the full knowledge of the underlying network topology and as such
   there is no need for the MDSC to send a path computation request to
   the PNC. The computation burden will fall on the MDSC to find an
   optimal end-to-end path and optimal per domain paths.

Lee, et. al.          Expires September 13, 2017               [Page 6]
Internet-Draft         ACTN Abstraction Methods              March 2017

                      +--+     +--+     +--+     +--+
                    +-+  +-----+  +-----+  +-----+  +-+
                      ++-+     ++-+     +-++     +-++
                       |        |         |        |
                       |        |         |        |
                       |        |         |        |
                       |        |         |        |
                      ++-+     ++-+     +-++     +-++
                    +-+  +-----+  +-----+  +-----+  +-+
                      +--+     +--+     +--+     +--+

                    Figure 1: The native/white topology

3.2. One Virtual Node (black topology)

   The entire domain network is abstracted as a single virtual node
   (see the definition of virtual node in [RFC7926]) with the
   access/egress links without disclosing any node internal
   connectivity information.

   Figure 2a depicts a native topology with the corresponding black
   topology with one virtual node and inter-domain links. In this case,
   the MDSC has to make path computation requests to the PNCs before it
   can determine an end-to-end path. If there are a large number of
   inter-connected domains, this abstraction method may impose a heavy
   coordination load at the MDSC level in order to find an optimal end-
   to-end path.

   Figure 2b depicts another type of a black topology with border nodes
   and inter-domain links.

   The black topology would not give the MDSC any critical network
   resource information other than the border nodes/links information
   and as such it is likely to have a need for complementary
   communications between the MDSC and the PNCs (e.g., Path Computation
   Request/Reply).

Lee, et. al.          Expires September 13, 2017               [Page 7]
Internet-Draft         ACTN Abstraction Methods              March 2017

                      +--+     +--+     +--+     +--+
                    +-+  +-----+  +-----+  +-----+  +-+
                      ++-+     ++-+     +-++     +-++
                       |        |         |        |
                       |        |         |        |
                       |        |         |        |
                       |        |         |        |
                      ++-+     ++-+     +-++     +-++
                    +-+  +-----+  +-----+  +-----+  +-+
                      +--+     +--+     +--+     +--+

                                +--------+
                             +--+        +--+
                                |        |
                                |        |
                                |        |
                                |        |
                                |        |
                                |        |
                             +--+        +--+
                                +--------+

    Figure 2a: The native topology and the corresponding black topology
               with one virtual node and inter-domain links

                                   -----
                                  (     )
                                (         )
                              +--+       +--+
                            +-+  |       |  +-+
                              +--+       +--+
                             (               )
                            (                 )
                             (               )
                              +--+       +--+
                            +-+  |       |  +-+
                              +--+       +--+
                                (         )
                                  (     )
                                   -----

Lee, et. al.          Expires September 13, 2017               [Page 8]
Internet-Draft         ACTN Abstraction Methods              March 2017

   Figure 2b: A black topology with border nodes and inter-domain links

3.3. Abstraction of TE tunnels for all pairs of border nodes (grey
   topology)

   This abstraction level, referred to a grey topology in [ACTN-frame]
   is between black topology and white topology from a granularity
   point of view. As shown in Figures 3a and 3b, we may further
   differentiate from a perspective of how to abstract internal TE
   resources between the pairs of border nodes:

     . Grey topology type A: border nodes with a TE links between them
        in a full mesh fashion (See Figure 3a)
     . Grey topology type B: border nodes with some internal
        abstracted nodes and abstracted links (See Figure 3b)

                      +--+     +--+     +--+     +--+
                    +-+  +-----+  +-----+  +-----+  +-+
                      ++-+     ++-+     +-++     +-++
                       |        |         |        |
                       |        |         |        |
                       |        |         |        |
                       |        |         |        |
                      ++-+     ++-+     +-++     +-++
                    +-+  +-----+  +-----+  +-----+  +-+
                      +--+     +--+     +--+     +--+

                               +--+    +--+
                             +-+  +----+  +-+
                               ++-+    +-++
                                |  \  /  |
                                |   \/   |
                                |   /\   |
                                |  /  \  |
                               ++-+    +-++
                             +-+  +----+  +-+
                               +--+    +--+

Lee, et. al.          Expires September 13, 2017               [Page 9]
Internet-Draft         ACTN Abstraction Methods              March 2017

    Figure 3a: The native topology and the corresponding grey topology
                 type A with TE links between border nodes

                          +--+     +--+     +--+
                        +-+  +-----+  +-----+  +-+
                          ++-+     ++-+     +-++
                           |                  |
                           |                  |
                           |                  |
                           |                  |
                          ++-+     ++-+     +-++
                        +-+  +-----+  +-----+  +-+
                          +--+     +--+     +--+

       Figure 3b: The grey topology type B with abstract nodes/links
                           between border nodes

3.3.1. Grey topology type A: border nodes with a TE links between them
   in a full mesh fashion

   For each pair of ingress and egress nodes (i.e., border nodes
   to/from the domain), TE link metric is provided with TE attributes
   such as max bandwidth available, link delay, etc. This abstraction
   depends on the underlying TE networks.

   Note that this topology is similar to the connectivity matrix
   defined in [TE-Topology]. The only thing might be different is some
   additional information about the end points of the links of the
   border nodes if they cannot be included in the connectivity matrix's
   termination points.

   - For packet networks, abstraction may include max bandwidth
     available, delay, etc.

   - 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

Lee, et. al.          Expires September 13, 2017              [Page 10]
Internet-Draft         ACTN Abstraction Methods              March 2017

     abstraction methods. Some OTN switches can switch any level of
     ODUs and in such case there is no need for ODU level abstraction.

   - 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.

3.3.2. Grey topology Type B

   The grey abstraction type B would allow the MDSC to have more
   information about the internals of the domain networks by the PNCs
   so that the MDSC can flexibly determine optimal paths. The MDSC may
   configure some of the internal virtual nodes (e.g., cross-connect)
   to redirect its traffic as it sees changes from the domain networks.

    3.4. How to build grey topology

   This section discusses two different methods of building a grey
   topology:

     . Automatic generation of abstract topology by configuration
        (Section 3.4.1)
     . On-demand generation of supplementary topology via path
        computation request/reply (Section 3.4.2)

3.4.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

Lee, et. al.          Expires September 13, 2017              [Page 11]
Internet-Draft         ACTN Abstraction Methods              March 2017

   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.4.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.4.1., additional
   supplementary topology may be obtained by the MDSC via path compute
   request/reply mechanism. Starting with a black topology
   advertisement from the PNCs, the MDSC may need additional
   information beyond the level of black topology from the PNCs. It is
   assumed that the black topology advertisement from PNCs would give
   the MDSC each domain's the border node/link information 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

Lee, et. al.          Expires September 13, 2017              [Page 12]
Internet-Draft         ACTN Abstraction Methods              March 2017

                      (       )              (       )
                       -------                -------

                 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.

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

Lee, et. al.          Expires September 13, 2017              [Page 13]
Internet-Draft         ACTN Abstraction Methods              March 2017

        o Other Level (TBD)

4.2. OTN Networks

   - 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:
             . 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 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)

   Note that Appendix A provides 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.

Lee, et. al.          Expires September 13, 2017              [Page 14]
Internet-Draft         ACTN Abstraction Methods              March 2017

5. Acknowledgements

   We thank Name 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

Lee, et. al.          Expires September 13, 2017              [Page 15]
Internet-Draft         ACTN Abstraction Methods              March 2017

   Email: zhang.xian@huawei.com

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

Appendix A:

   This section provides how WSON grey topology abstraction levels 1
   and 2 can be computed at a PNC. These examples illustrate that the
   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,

Lee, et. al.          Expires September 13, 2017              [Page 16]
Internet-Draft         ACTN Abstraction Methods              March 2017

  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 September 13, 2017              [Page 17]