Subject: [Actn] ACTN Charter Proposal v1.2

From: "King, Daniel" <[email-masked]>
Date: Fri, 19 Sep 2014 22:41:35 +0000

Hi All, 

Please find version v1.2 of the charter. 

This version addresses/includes comments from: Dhruv Dhody, Eve Varma, Mike Mossbarger, Nico Wauters, Daniele Ceccarelli, Sergio Belotti, Aihua Guo, Richard Yang, and Xu Yunbin. 

Transport networks are defined as network infrastructure that provides
connectivity and bandwidth for customer services. They are characterized
by their ability to support server layer provisioning and traffic
engineering for client layer services, such that resource guarantees may
be provided to their customers. Transport networks here refer to a set
of different type of connection-oriented networks, which include
Connection-Oriented Circuit Switched (CO-CS) networks and Connection-
Oriented Packet Switched (CO-PS) networks. This implies that at least
the following transport networks are in scope: Layer 1 (L1) and Layer 0
(L0) optical networks (e.g., OTN, ODU, OCh/WSON), MPLS-TP, MPLS-TE, as
well as other emerging network technologies with connection-oriented
behavior.

Transport networks have a variety of mechanisms to:

- Facilitate separation of data plane and control plane,

- Allow for distributed signaling or centralized models (e.g., NMS-
  based or centralized signaling) for path setup and protection, and

- Provide traffic engineering mechanism via centralized path
  computation.

These represent key technologies for enabling flexible and dynamic
networking, and efficient control and recovery of resources. Although
these technologies provide significant benefits within a single domain
control boundary, they do not meet the growing need for transport
network virtualization in multi-domain transport networks. More and more
network operators are building and operating on multi-domain transport
networks. These domains (collections of links and nodes) may be each of
a different technology, administrative zones, or vendor-specific
islands. Establishment of end-to-end connections spanning multiple
domains is a perpetual problem for operators because of both operational
concerns (control plane and management plane) and interoperability
issues (control plane and data plane).  Due to these issues, new
services that require connections that traverse multiple domains need
significant planning and often manual operations to interface different
vendor equipment and technology.

The aim of Abstraction and Control of Transport Networks (ACTN) is to
facilitate a centralized virtual network operation: the creation of a
virtualized environment allowing operators to view and control multi-
subnet, multi-technology, multi-vendor domain networks. This will enable
rapid service deployment of new dynamic and elastic services, and will
improve overall network operations and scaling of existing services.
Discussion with operators has also highlighted a need for operation of
virtual networks based on the abstraction of underlying technology and
vendor domains. Abstraction of transport networks also allows operators
to consolidate their network services into multi-tenant virtual
transport networks.

Multi-domain network coordination function in ACTN is built on a control
hierarchy where a multi-domain coordinator interacts with the control
mechanism for each domain (e.g., EMS/NMS, GMPLS/PCE control plane, SDN
controller) to represent abstraction of network resources and to provide
control functions for virtual networks. These control functions enable
various services/clients/applications to create and manage their own
virtual networks that share the common transport network resources.

The ACTN working group will work to develop a high-level architecture
for transport network abstraction and control that facilitates seamless
vertical service coordination across multi-tenant customers (primarily
internal service organizations with respect to a network operator), the
control of virtual and physical network domains, as well as a horizontal
E2E service coordination across multi-domain networks. It will identify
key building components and the corresponding interfaces among these
components. Key components can be future building block or legacy
components existing today. The architecture work will lead to
requirements for information models and protocol extensions for
communication between the components.

Well-defined use cases from operators perspective with clearly stated
need for transport network virtualization are critical in scoping the
work and thus to achieve the deliverables of the working group.

The working group will work on the following items:

- High-level architecture that describes the basic building blocks to
  enable transport network virtualization to support use cases.

- Operator-driven use cases to address the following initial items:
  o Control and operation of virtual networks for core transport Packet
    Optical Integration (POI). (e.g., MPLS-TP, OTN/WSON)
  o Control and operation of virtual networks for mobile backhaul multi-
    technology transport (e.g., MPLS-TP and MPLS/OTN)
  o Data Center Operator's interconnection with optical transport
    network infrastructure providers to support dynamic virtual circuit
    services.
  o Multi-tenant support to allow virtual network information query,
    virtual network negotiation, creation/deletion and modification.
  o Synchronization of network resources view across control of physical
    and virtual networks.
  o Dynamic service control and monitoring across all entities.

  Initial work within the working group will be limited to a single
  operator administrative domain with an exception for the Data Center
  operation use case.

- Evaluation of Information model/data model to support the use cases.

- Requirements to support APIs/protocols, encoding languages, and data
  models

- Gap analysis of existing IETF and other protocols, encoding languages
  and data models to fulfil the requirements

- Protocol extensions (if necessary after re-chartering)

- Issues of security, privacy, and trust in mechanisms that provide
  control and abstraction across domain boundaries (and therefore across
  trust boundaries)

The working group will determine if new protocol or extensions to
existing protocols are necessary. If the working group determines they
are necessary, then it will develop new protocols within the working
group; on the other hand, any extensions to existing protocols would be
done with interactions with other working groups where possible.

Where the need for data models is identified, the working group will
first examine data models already developed by other working groups.
<<

The current charter text (and previous versions) is available at https://sites.google.com/site/actnbof/home/charter-proposal.

Br, Dan.