Skip to main content

ACTN Use-case for On-demand E2E Connectivity Services in Multiple Vendor Domain Transport Networks
draft-klee-actn-connectivity-multi-vendor-domains-00

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".
Author Kwang-koog Lee
Last updated 2014-06-04
RFC stream (None)
Formats
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-klee-actn-connectivity-multi-vendor-domains-00
Network Working Group                                    Kwang-koog Lee
Internet Draft                                                       KT
Intended status: Informational
Expires December 2014

                                                           June 4, 2014

      ACTN Use-case for On-demand E2E Connectivity Services in Multiple
                      Vendor Domain Transport Networks

         draft-klee-actn-connectivity-multi-vendor-domains-00.txt

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 4, 2014.

Copyright Notice

   Copyright (c) 2014 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.

K. Lee                 Expires December 4, 2014                [Page 1]
Internet-Draft       ACTN Multiple Vendor Domains             June 2014

Abstract

   This document provides a use-case that addresses the need for
   facilitating the application of virtual network abstractions and the
   control and management of on-demand end-to-end provisioning of
   connections that traverse multiple vendor domain transport networks.

   These abstractions shall help create a virtualized environment
   supporting operators in viewing and controlling different vendor
   domains, especially for on-demand network connectivity service for a
   single operator.

Table of Contents

    1. Introduction..................................................2
   2. On-demand End-to-end Connectivity in Multi-vendor Domain
   Transport Networks................................................3
   3. Requirements...................................................4
   4. References.....................................................6
   5. Contributors...................................................7
   Intellectual Property Statement...................................7
   Disclaimer of Validity............................................7

1. Introduction

   Network operators build and operate their network using multiple
   domains in different dimensions. Domains may be defined by a
   collection of links and nodes (each of a different technology),
   administrative zones under the concern of a particular business
   entity, or vendor-specific "islands" where specific control
   mechanisms have to be applied.  Establishing end-to-end connections
   spanning several of these domains is a perpetual problem for
   operators, which need to address both interoperability and
   operational concerns at the control and data planes.

   The introduction of new services, often requiring connections that
   traverse multiple domains, needs significant planning, and several
   manual operations to interface multiple vendor-specific domains in
   which specific control/management mechanisms of the vendor equipment
   have to be applied (e.g., EMS/NMS, OSS/BSS, control plane, SDN
   controller, etc.).

   This document provides a use-case that addresses the need for
   creating a virtualized environment supporting operators in viewing
   and controlling different vendor domains, especially for on-demand
   network connectivity service for a single operator. This will
   accelerate rapid service deployment of new services, including more

   K. Lee            Expires December 4, 2014   [Page 2]
Internet-Draft       ACTN Multiple Vendor Domains             June 2014

   dynamic and elastic services, and improve overall network operations
   and scaling of existing services.

   This use-case is a part of the overarching work, called Abstraction
   and Control of Transport Networks (ACTN). Related documents are the
   ACTN-framework [ACTN-Frame] and the problem statement [ACTN-PS].

2. On-demand End-to-end Connectivity in Multi-vendor Domain Transport
   Networks

   This section provides an architecture example to illustrate the
   context of the current challenges and issues operators face in
   delivering on-demand end-to-end connectivity services in operators'
   multi-vendor domain transport networks.

                                                                   |
     | /                    End-to-End Connection                \ |
     |/-----------------------------------------------------------\|
     |\-----------------------------------------------------------/|
     | \                                                         / |
     |                                                             |
     |                      +----------------+                     |
     |                      |                |                     |
     |                      |    Converged   |                     |
     |                      |  Packet-Optical|                     |
     |     +-------------+  |    Core Domain |  +-------------+    |
     |     |             |--|   (Vendor A)   |--|             |    |
   +----+  |    Access   |  +----------------+  |    Access   |  +----+
   | CE1|--|   Domain 1  |     |          |     |   Domain 3  |--| CE2|
   +----+  |  (Vendor B) |-----            -----|  (Vendor C) |  +----+
           +-------------+                      +-------------+

                      Figure 1. Multi-vendor Domains

   As an illustrative example, consider a multi-domain transport
   network consisting of three domains: One Core Converged Packet-
   Optical Domain (Vendor A) and two access domains (Vendors B and C).
   Each access domain is managed by its domain control/management
   mechanism which is often a proprietary vendor-specific scheme. The
   core domain is also managed by Vendor A's proprietary
   control/management mechanism (e.g., EMS/NMS, OSS/BSS, ASON/GMPLS
   Control Plane, SDN Controller, or any combination of these entities,
   etc.) that may not interoperate with access domain
   control/management mechanisms or at best partially interoperate if
   Vendor A is same as Vendor B or Vendor C.

   K. Lee            Expires December 4, 2014   [Page 3]
Internet-Draft       ACTN Multiple Vendor Domains             June 2014

   Due to these domain boundaries, facilitating on-demand end-to-end
   connections (e.g., Ethernet Virtual Connections, etc.) that traverse
   multi-domains is not readily achieved. These domain controls are
   optimized for its local operation and in most cases not suited for
   controlling the end-to-end connectivity services. For instance, the
   discovery of the Client Ends (CE) that belong to other domains is
   hard to achieve partly because of the lack of the common API and its
   information model and control mechanisms thereof to disseminate the
   relevant information.

   Moreover, the path computation for any on-demand end-to-end
   connection would need abstraction of dynamic network resources and
   ways to find an optimal path that meets the connection's service
   requirements. This would require knowledge of both the domain level
   dynamic network resource information and the inter-domain
   connectivity information including domain gateway/peering points and
   the local domain policy.

   From an on-demand connection provisioning perspective, in order to
   facilitate a fast and reliable end-to-end signaling, each domain
   operation and management elements should ideally speak the same
   control protocols to its neighboring domains. However, this is not
   possible for the current network context unless a folk-lift green
   field technology deployment with a single vendor solution would be
   done.

   From a network connectivity management perspective, it would require
   a mechanism to disseminate any connectivity issues from the local
   domain to the other domains whenever the local domain cannot resolve
   a connectivity issues. This is hard to achieve due to the lack of
   the common API and its agreed-upon information model and control
   mechanisms thereof to disseminate the relevant information.

   From an operation's perspective, the current network environments
   are not conducive to offering on-demand end-to-end connectivity
   services in multi-vendor domain transport networks.

3. Requirements

   In the previous section, we discussed the current challenges and
   issues that prevent operators from offering on-demand end-to-end
   connectivity services in multi-vendor domain transport networks.

   This section provides a high-level requirement for enabling on-
   demand end-to-end connectivity services in multi-vendor domain
   transport networks in a single operator environment.

   Figure 1 shows information flow requirements of the aforementioned
   context.

   K. Lee            Expires December 4, 2014   [Page 4]
Internet-Draft       ACTN Multiple Vendor Domains             June 2014

            +-------------------------------------------------+
            |                                                 |
            |         Customer On-demand Network Service      |
            |                                                 |
            +-------------------------------------------------+
                                    /|\
                                     |
                                    \|/
            +-------------------------------------------------+
            |                                                 |
            |               Abstracted Global View            |
            |                                                 |
            +-------------------------------------------------+
                                    /|\
                                     |
                                    \|/
            +-------------------------------------------------+
            |                                                 |
            |        Single Integrated E2E Network View       |
            |                                                 |
            +-------------------------------------------------+
                  /|\              /|\               /|\
                   |                |                 |
                  \|/              \|/               \|/
            +-------------+   +-------------+   +-------------+
            |             |   |             |   |             |
            |  Domain A   |   |  Domain B   |   |  Domain C   |
            |   Control   |   |   Control   |   |   Control   |
            +-------------+   +-------------+   +-------------+

      Figure 2. Information Flow Requirements for Enabling On-demand
       Network Connectivity Service in Multi-vendor Domain Networks

   There are a number of key requirements from Figure 2.

   - A single integrated end-to-end network view is necessary to be
     able to compute paths and provision the end-to-end paths that
     traverse multiple vendor domains.

   - The entity responsible to collect domain-level data and create an
     integrated end-to-end view should support push/pull model with
     respect to all its interfaces.

   - The same entity should coordinate a signaling flow for an end-to-
     end connections to each domain involved. (This entity to domain
     control is analogous to an NMS to EMS relationship)

   K. Lee            Expires December 4, 2014   [Page 5]
Internet-Draft       ACTN Multiple Vendor Domains             June 2014

   - The entity responsible to create abstract global view should
     support push/pull model with respect to all its interfaces. (Note
     that the two entities (an entity to create an integrated end-to-
     end view and an entity to create an abstracted global view) can be
     assumed by the same entity, which is an implementation issue.

   - There is a need for a common API between each domain control to
     the entity that is responsible for creating a single integrated
     end-to-end network view. At the minimum, the following items are
     required on the API:

        o Programmability of the API.

        o The multiple levels/granularities of the abstraction of
          network resource (which is subject to policy and service
          need).

        o The abstraction of network resource should include customer
          end points and inter-domain gateway nodes/links.

        o Any physical network constraints (such as SRLG, link
          distance, etc.) should be reflected in abstraction.

        o Domain preference and local policy (such as preferred peering
          point(s), preferred route, etc.)

        o Domain network capability (e.g., support of push/pull model).

   - The entity responsible for abstraction of a global view into a
     customer view should provide a programmable API to allow the
     flexibility.

        o Abstraction of a global view into a customer view should be
          provided to allow customer to dynamically request network on-
          demand services including connectivity services.

        o What level of details customer should be allowed to view
          network is subject to negotiation between the customer and
          the operator.

4. References

   [ACTN-Frame] D. Ceccarelli, L. Fang, Y. Lee and D. Lopez, "Framework
             for Abstraction and Control of Transport Networks," draft-
             ceccarelli-actn-framework, work in progress.

   K. Lee            Expires December 4, 2014   [Page 6]
Internet-Draft       ACTN Multiple Vendor Domains             June 2014

   [ACTN-PS] Y. Lee, D. King, M. Boucadair, R. Jing, and L. Murillo,
             "Problem Statement for the Abstraction and Control of
             Transport Networks," draft-leeking-actn-problem-statement,
             work in progress.

5. Contributors

Authors' Addresses

   Kwang-koog Lee

   KT
   Email: kwangkoog.lee@kt.com

Intellectual Property Statement

   The IETF Trust takes no position regarding the validity or scope of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the technology
   described in any IETF Document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat and any assurances of licenses to be made available, or
   the result of an attempt made to obtain a general license or
   permission for the use of such proprietary rights by implementers or
   users of this specification can be obtained from the IETF on-line
   IPR repository at http://www.ietf.org/ipr

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.

Disclaimer of Validity

   All IETF Documents and the information contained therein are
   provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
   HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
   THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE

   K. Lee            Expires December 4, 2014   [Page 7]
Internet-Draft       ACTN Multiple Vendor Domains             June 2014

   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

   K. Lee            Expires December 4, 2014   [Page 8]