[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-ccamp-transport-nbi-use-cases

CCAMP Working Group                                      I. Busi (Ed.)
Internet Draft                                                 Huawei
Intended status: Informational                                D. King
                                                  Lancaster University

Expires: December 2017                                   July 03, 2017




                 Transport Northbound Interface Use Cases
               draft-tnbidt-ccamp-transport-nbi-use-cases-02


Status of this Memo

   This Internet-Draft is submitted 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 28, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.



Busi & King, et al.   Expires December 28, 2017               [Page 1]


Internet-Draft         Transport NBI Use Cases               June 2017


Abstract

   Transport network domains, including Optical Transport Network (OTN)
   and Wavelength Division Multiplexing (WDM) networks, are typically
   deployed based on a single vendor or technology platforms. They are
   often managed using proprietary interfaces to dedicated Element
   Management Systems (EMS), Network Management Systems (NMS) and
   increasingly Software Defined Network (SDN) controllers.

   A well-defined open interface to each domain management system or
   controller is required for network operators to facilitate control
   automation and orchestrate end-to-end services across multi-domain
   networks. These functions may be enabled using standardized data
   models (e.g. YANG), and appropriate protocol (e.g., RESTCONF).

   This document describes the key use cases and requirements for
   transport network control and management. It reviews proposed and
   existing IETF transport network data models, their applicability,
   and highlights gaps and requirements.

Table of Contents

   1. Introduction..................................................3
   2. Conventions used in this document.............................3
   3. Use Case 1: Single-domain with single-layer...................3
      3.1. Reference Network........................................3
         3.1.1. Single Transport Domain - OTN Network...............4
      3.2. Topology Abstractions....................................6
      3.3. Service Configuration....................................7
         3.3.1. ODU Transit.........................................7
         3.3.2. EPL over ODU........................................8
         3.3.3. Other OTN Client Services...........................8
         3.3.4. EVPL over ODU.......................................9
         3.3.5. EVPLAN and EVPTree Services.........................9
         3.3.6. Virtual Network Services............................9
      3.4. Multi-functional Access Links............................9
      3.5. Protection Scenarios.....................................9
         3.5.1. Linear Protection...................................10
   4. Use Case 2: Single-domain with multi-layer....................11
   5. Use Case 3: Multi-domain with single-layer....................11
   6. Use Case 4: Multi-domain and multi-layer......................11
   7. Security Considerations.......................................11
   8. IANA Considerations...........................................11
   9. References....................................................11
      9.1. Normative References.....................................11
      9.2. Informative References...................................11
   10. Acknowledgments..............................................12


Busi & King, et al.   Expires December 28, 2017               [Page 2]


Internet-Draft         Transport NBI Use Cases               June 2017



1. Introduction

   A common open interface to each domain controller/management system
   is pre-requisite for network operators to control multi-vendor and
   multi-domain networks and enable also service provisioning
   coordination/automation. This can be achieved by using standardized
   YANG models, used together with an appropriate protocol (e.g.,
   RESTCONF).

   This document assumes a reference architecture, including
   interfaces, based on the Abstraction and Control of Traffic-
   Engineered Networks (ACTN), defined in [ACTN-Frame].

   The focus of the current version is on the MPI (interface between
   the Multi Domain Service Coordinator (MDSC) and a Physical Network
   Controller (PNC), controlling a transport network domain).

   The relationship between the current IETF YANG models and the type
   of ACTN interfaces can be found in [ACTN-YANG].

   The ONF Technical Recommendations for Functional Requirements for
   the transport API, may be found in [ONF TR-527].
   Furthermore, ONF transport API multi-layer examples may be found in
   [ONF GitHub].

   This document describes use cases that could be used for analyzing
   the applicability of the existing models defined by the IETF for
   transport networks

   Considerations about the CMI (interface between the Customer Network
   Controller (CNC) and the MDSC) are for further study.

2. Conventions used in this document

   For discussion in future revisions of this document.

3. Use Case 1: Single-domain with single-layer

3.1. Reference Network

   The current considerations discussed in this document are based on
   the following reference networks:

     - single transport domain: OTN network




Busi & King, et al.   Expires December 28, 2017               [Page 3]


Internet-Draft         Transport NBI Use Cases               June 2017


   It is expected that future revisions of the document will include
   additional reference networks.

3.1.1. Single Transport Domain - OTN Network

   Figure 1 shows the network physical topology composed of a single-
   domain transport network providing transport services to an IP
   network through five access links.

           ................................................
           :                 IP domain                    :
           :        ..............................        :
           :        :  ........................  :        :
           :        :  :                      :  :        :
           :        :  :      S1 -------- S2 ------ C-R4  :
           :        :  :     /             |  :  :        :
           :        :  :    /              |  :  :        :
           :  C-R1 ------ S3 ----- S4      |  :  :        :
           :        :  :    \        \     |  :  :        :
           :        :  :     \        \    |  :  :        :
           :        :  :      S5       \   |  :  :        :
           :  C-R2 -----+    /  \       \  |  :  :        :
           :        :  : \  /    \       \ |  :  :        :
           :        :  :  S6 ---- S7 ---- S8 ------ C-R5  :
           :        :  : /                    :  :        :
           :  C-R3 -----+                     :  :        :
           :        :  :   Transport domain   :  :        :
           :        :  :                      :  :        :
           :........:  :......................:  :........:
                  Figure 1 Reference network for Use Case 1

   The IP and transport (OTN) domains are respectively composed by five
   routers C-R1 to C-R5 and by eight ODU switches S1 to S8. The
   transport domain acts as a transit domain providing connectivity to
   the IP layer.

   The behavior of the transport domain is the same whether the
   ingress/egress nodes in the IP domain, supporting an IP service, are
   directly attached to the transport domain or there are other routers
   in between the ingress/egress nodes of the IP domain and the routers
   directly attached to the transport network.








Busi & King, et al.   Expires December 28, 2017               [Page 4]


Internet-Draft         Transport NBI Use Cases               June 2017


                                 +-----+
                                 | CNC |
                                 +-----+
                                    |
                                    |CMI I/F
                                    |
                         +-----------------------+
                         |         MDSC          |
                         +-----------------------+
                                    |
                                    |MPI I/F
                                    |
                                +-------+
                                |  PNC  |
                                +-------+
                                    |
                                  -----
                                (       )
                               (   OTN   )
                              ( Physical  )
                               ( Network )
                                (       )
                                  -----

                Figure 2 Controlling Hierarchy for Use Case 1

   The mapping of the client IP traffic on the physical link between
   the routers and the transport network is made in the IP routers only
   and is not controlled by the transport PNC and is transparent to the
   transport nodes.

   The control plane architecture follows the ACTN architecture and
   framework document [ACTN-Frame]. The Client Controller act as a
   client with respect to the Multi-Domain Service Coordinator (MDSC)
   via the Controller-MDSC Interface (CMI). The MDSC is connected to a
   plurality of Physical Network Controllers (PNCs), one for each
   domain, via a MDSC-PNC Interface (MPI). Each PNC is responsible
   only for the control of its domain and the MDSC is the only entity
   capable of multi-domain functionalities as well as of managing the
   inter-domain links. The key point of the whole ACTN framework is
   detaching the network and service control from the underlying
   technology and help the customer express the network as desired
   by business needs. Therefore, care must be taken to keep minimal
   dependency on the CMI (or no dependency at all) with respect to
   the network domain technologies. The MPI instead requires some
   specialization according to the domain technology.



Busi & King, et al.   Expires December 28, 2017               [Page 5]


Internet-Draft         Transport NBI Use Cases               June 2017


   In this section, we address the case of an IP and a Transport PNC
   having respectively an IP a Transport MPI. The interface within
   the scope of this document is the Transport MPI while the IP Network
   MPI is out of its scope and considerations about the CMI are for
   further study.

3.2. Topology Abstractions

   There are multiple methods to abstract a network topology. This
   document assumes the abstraction method defined in [RFC7926]:

     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.

   [TE-Topo] describes a YANG base model for TE topology without any
   technology specific parameters. Moreover, it defines how to abstract
   for TE-network topologies.

   [ACTN-Abstraction] provides the context of topology abstraction in
   the ACTN architecture and discusses a few alternatives for the
   abstraction methods 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.  According
   to [ACTN-Abstraction], there are three types of topology:

   o White topology: This is a case where the Physical Network
      Controller (PNC) provides the actual network topology to the
      Multi-domain Service Coordinator (MDSC) without any hiding or
      filtering. In this case, the MDSC has the full knowledge of the
      underlying network topology.

   o Black topology: The entire domain network is abstracted as a
      single virtual node with the access/egress links without
      disclosing any node internal connectivity information.

   o Grey topology: This abstraction level is between black topology
      and white topology from a granularity point of view. This is
      abstraction of TE tunnels for all pairs of border nodes. We may
      further differentiate from a perspective of how to abstract
      internal TE resources between the pairs of border nodes:



Busi & King, et al.   Expires December 28, 2017               [Page 6]


Internet-Draft         Transport NBI Use Cases               June 2017


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

        - Grey topology type B: border nodes with some internal
          abstracted nodes and abstracted links.

   For single-domain with single-layer use-case, the white topology may
   be disseminated from the PNC to the MDSC in most cases. There may be
   some exception to this in the case where the underlay network may
   have complex optical parameters, which do not warrant the
   distribution of such details to the MDSC. In such case, the topology
   disseminated from the PNC to the MDSC may not have the entire TE
   information but a streamlined TE information. This case would incur
   another action from the MDSC's standpoint when provisioning a path.
   The MDSC may make a path compute request to the PNC to verify the
   feasibility of the estimated path before making the final
   provisioning request to the PNC, as outlined in [Path-Compute].

   Topology abstraction for the CMI is for further study (to be
   addressed in future revisions of this document).

3.3. Service Configuration

   In the following use cases, the Multi Domain Service Coordinator
   (MDSC) needs to be capable to request service connectivity from the
   transport Physical Network Controller (PNC) to support IP routers
   connectivity. The type of services could depend of the type of
   physical links (e.g. OTN link, ETH link or SDH link) between the
   routers and transport network.

   As described in section 3.1.1, the control of different adaptations
   inside IP routers, C-Ri (PKT -> foo) and C-Rj (foo -> PKT), are
   assumed to be performed by means that are not under the control of,
   and not visible to, transport PNC. Therefore, these mechanisms are
   outside the scope of this document.

3.3.1. ODU Transit

   This use case assumes that the physical link interconnecting IP
   routers and transport network is an OTN link.

   The physical/optical interconnection is supposed to be a pre-
   configured and not exposed via MPI to MDSC.

   If we consider the case of a 10Gb IP link between C-R1 to C-R3,we
   need to instantiate an ODU2 end-to-end connection between C-R1 and
   C-R3, crossing transport nodes S3, S5, and S6.


Busi & King, et al.   Expires December 28, 2017               [Page 7]


Internet-Draft         Transport NBI Use Cases               June 2017


   The traffic flow between C-R1 and C-R3 can be summarized as:

      C-R1 (PKT -> ODU2), S3 (ODU2), S5 (ODU2), S6 (ODU2),
      C-R3 (ODU2 -> PKT)

   The MDSC should be capable via MPI interface to request the setup of
   ODU2    transit service with enough information that can permit
   transport   PNC to instantiate and control the ODU2 segment through
   nodes S3, S5, S6.

3.3.2. EPL over ODU

   This use case assumes that the physical link interconnecting IP
   routers and transport network is an Ethernet link.

   If we consider the case of a 10Gb IP link between C-R1 to C-R3, we
   need to instantiate an EPL service between C-R1 and C-R3 supported
   by an ODU2 end-to-end connection between S3 and S6, crossing
   transport node S5.

   The traffic flow between C-R1 and C-R3 can be summarized as:

      C-R1 (PKT -> ETH), S3 (ETH -> ODU2), S5 (ODU2),
      S6 (ODU2 -> ETH), C-R3 (ETH-> PKT)

   The MDSC should be capable via MPI i/f to request the setup of EPL
   service with enough information that can permit transport PNC to
   instantiate and control the ODU2 end-to-end connection through nodes
   S3, S5, S6, as well as the adaptation functions inside S3 and S6:
   S3&S6 (ETH -> ODU2) and S9&S6 (ODU2 -> ETH).

3.3.3. Other OTN Client Services

   [ITU-T G.709-2016] defines mappings of different client layers into
   ODU. Most of them are used to provide Private Line services over
   an OTN transport network supporting a variety of types of physical
   access links (e.g., Ethernet, SDH STM-N, Fibre Channel,
   InfiniBand,).

   This use case assumes that the physical links interconnecting IP
   routers and transport network are any one of these possible options.

   If we consider the case of a 10Gb IP link between C-R1 to C-R3
   using SDH physical links, we need to instantiate an STM-64 Private
   Line service between C-R1 and C-R3 supported by an ODU2 end-to-end
   connection between S3 and S6, crossing transport node S5.



Busi & King, et al.   Expires December 28, 2017               [Page 8]


Internet-Draft         Transport NBI Use Cases               June 2017


   The traffic flow between C-R1 and C-R3 can be summarized as:

      C-R1 (PKT -> STM-64), S3 (STM-64 -> ODU2), S5 (ODU2),
      S6 (ODU2 -> STM-64), C-R3 (STM-64 -> PKT)

   The MDSC should be capable via MPI i/f to request the setup of an
   STM-64 Private Line service with enough information that can permit
   transport PNC to instantiate and control the ODU2 end-to-end
   connection through nodes S3, S5, S6, as well as the adaptation
   functions inside S3 and S6: S3&S6 (STM-64 -> ODU2) and S9&S3 (STM-64
   -> PKT).

3.3.4. EVPL over ODU

   For future revision.

3.3.5. EVPLAN and EVPTree Services

   For future revision.

3.3.6. Virtual Network Services

   For future revision.

3.4. Multi-functional Access Links

   For future revision.

3.5. Protection Scenarios

   The MDSC needs to be capable to request the transport PNC to
   configure protection when requesting the setup of the connectivity
   services described in section 3.3.

   [Editor's note (for DT discussion):] Should we describe only
   protection or also restoration scenarios?

   Since in this use case it is assumed that switching is performed
   only in one layer, the OTN ODU layer, for all the services defined
   in section 3.3, protection can only be provided at that same layer.

   Resiliency mechanisms on the access link are considered outside the
   scope of this use case.

   [Editor's note (for DT discussion):] I think that scenarios with
   access link resiliency could be seen as being multi-domain and/or
   multi-layer. For further discussion with DT members.


Busi & King, et al.   Expires December 28, 2017               [Page 9]


Internet-Draft         Transport NBI Use Cases               June 2017


3.5.1. Linear Protection

   It is possible to protect any service defined in section 3.3 from
   failures within the OTN transport domain by configuring a linear
   protection group, as defined in [ITU-T G.808.1], in the data plane
   between node S3 and node S6.

   [Editor's note:] Check for IETF references about protection
   definitions.

   The OTN linear protection group can be configured to operate as 1+1
   unidirectional, 1+1 bidirectional (to check) or 1:n bidirectional,
   as defined in [ITU-T G.808.1] and [ITU-T G.873.1].

   [Editor's note (for DT discussion):] The most common protection
   mechanism used in OTN networks is 1+1 unidirectional. Should we
   consider also the other cases?

   In these scenarios, a working transport entity and a protection
   transport entity, as defined in [ITU-T G.808.1], should be
   configured in the data plane:

     Working transport entity: S3 -> S5 -> S6

     Protection transport entity: S3 -> S4 -> S6 -> S7 -> S6

   Requirements about how the MDSC could be capable to request the
   transport PNC to configure the protection group are for further
   study.

   [Editor's note:] Need to discuss whether MDSC should decide that
   linear protection is needed and whether it should be 1+1 or 1:1 or
   whether the transport PNC can take this decision based on other
   information provided by MDSC (or whether both options are possible).

   The Transport PNC should be capable to report to the MDSC which is
   the active transport entity, as defined in [ITU-T G.808.1], in the
   data plane.

   Given the fast dynamic of protection switching operations in the
   data plane (50ms recovery time), this reporting is not expected to
   be in real-time.

   It is also worth noting that with unidirectional protection
   switching, e.g., 1+1 unidirectional, the active transport entity may
   be different in the two directions.



Busi & King, et al.   Expires December 28, 2017              [Page 10]


Internet-Draft         Transport NBI Use Cases               June 2017


4. Use Case 2: Single-domain with multi-layer

   For future revision.

5. Use Case 3: Multi-domain with single-layer

   For future revision.

6. Use Case 4: Multi-domain and multi-layer

   For future revision.

7. Security Considerations

   For further study.

8. IANA Considerations

   This document requires no IANA actions.

9. References

9.1. Normative References

   [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for
             Information Exchange between Interconnected Traffic-
             Engineered Networks", BCP 206, RFC 7926, July 2016.

   [ITU-T G.709-2016] G.808.1 G.709 (06/16), "Interfaces
             for the optical transport network", June 2016.

   [ITU-T G.808.1] ITU-T Recommendation G.808.1, "Generic protection
             switching - Linear trail and subnetwork protection", May
             2014.

   [ITU-T G.873.1] ITU-T Recommendation G.873.1, "Optical transport
             network (OTN): Linear protection", May 2014.

   [ACTN-Frame] Ceccarelli, D., Lee, Y. et al., "Framework for
             Abstraction and Control of Transport Networks", draft-
             ietf-teas-actn-framework, work in progress.

   [ACTN-Abstraction]  Lee, Y. et al., "Abstraction and Control of TE
             Networks (ACTN) Abstraction Methods", draft-lee-teas-actn-
             abstraction, work in progress.

9.2. Informative References

   [TE-Topo] Liu, X. et al., "YANG Data Model for TE Topologies",
             draft-ietf-teas-yang-te-topo, work in progress.


Busi & King, et al.   Expires December 28, 2017              [Page 11]


Internet-Draft         Transport NBI Use Cases               June 2017


   [ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for
             Abstraction and Control of Traffic Engineered Networks",
             draft-zhang-teas-actn-yang, work in progress.

   [Path-Compute] Busi, I., Belotti, S. et al., " Yang model for
             requesting Path Computation", draft-busibel-teas-yang-
             path-computation, work in progress.

   [ONF TR-527] ONF Technical Recommendation TR-527, "Functional
             Requirements for Transport API", June 2016.

   [ONF GitHub] ONF Open Transport (SNOWMASS)
             https://github.com/OpenNetworkingFoundation/Snowmass-
             ONFOpenTransport

10. Acknowledgments

   The authors would like to thank all members of the Transport NBI
   Design Team involved in the definition of use cases, gap analysis
   and guidelines for using the IETF YANG models at the Northbound
   Interface (NBI) of a Transport SDN Controller.

   The authors would like to thank Xian Zhang, Anurag Sharma, Sergio
   Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar
   Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated
   the work on gap analysis for transport NBI and having provided
   foundations work for the development of this document.

   This document was prepared using 2-Word-v2.0.template.dot.





















Busi & King, et al.   Expires December 28, 2017              [Page 12]


Internet-Draft         Transport NBI Use Cases               June 2017


Authors' Addresses

   Italo Busi (Editor)
   Huawei
   Email: italo.busi@huawei.com

   Daniel King (Editor)
   Lancaster University
   Email: d.king@lancaster.ac.uk

   Sergio Belotti
   Nokia
   Email: sergio.belotti@nokia.com

   Gianmarco Bruno
   Ericsson
   Email: gianmarco.bruno@ericsson.com

   Young Lee
   Huawei
   Email: leeyoung@huawei.com

   Victor Lopez
   Telefonica
   Email: victor.lopezalvarez@telefonica.com

   Carlo Perocchio
   Ericsson
   Email: carlo.perocchio@ericsson.com

   Haomian Zheng
   Huawei
   Email: zhenghaomian@huawei.com















Busi & King, et al.   Expires December 28, 2017              [Page 13]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/