Re: [Actn] charter 1.4

[Leeyoung <[e-mail]>]

Hi Peter,

I support your more compact description of transport networks.

Let's wait if there are other opinions.

Thanks,
Young

From: AshwoodsmithPeter
Sent: Tuesday, December 09, 2014 1:44 PM
To: Leeyoung; Zhenghaomian; [e-mail]
Subject: RE: [Actn] charter 1.4


Young,

I offer up a slightly more compact but mostly equivalent first few sentences for your consideration. I also think its cleaner if you describe the services as being CO rather than the network being CO.

"Transport networks are defined as network infrastructure that provides connection oriented,  bandwidth guaranteed and resilient connectivity as client layer services. Both Connection-Oriented Circuit Switched (CO-CS) and Connection-Oriented Packet Switched services are in scope. This implies that at least the following transport networks are in scope...."

Peter


Abstraction and Control of Transport Networks (ACTN)

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
virtual network coordination based on the abstraction of underlying
technology and vendor domains as well as virtual service coordination
based on service-related knowledge. Abstraction of transport networks
also allows operators to consolidate their network services into
multi-tenant virtual transport networks.

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

Virtual service coordination function in ACTN incorporates
customer's service-related knowledge in virtual network operation in order to
seamlessly operate virtual networks while meeting customer's service
requirements.

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

The ACTN working group works to develop a high-level architecture that
describes the basic building-blocks necessary to enable the multi-domain
virtual service coordination. It will identify key building components and
the corresponding interfaces among these components. The Key components can
be future building block or legacy components existing today. It will
clearly show the  interaction between the customer controller
and the virtual network controller, and the virtual network controller and
the physical network controllers with possibility for recursion.

The ACTN working group will develop the requirements for these interfaces
and extend existing protocols and data models if necessary with coordination
with other WGs  or to develop new protocols and data models uniquely identified
in scope of ACTN WG.

The ACTN WG will coordinate with the following working groups:

- With the TEAS WG regarding TE architecture and generic TE
   Information and Data Model. ACTN will extend these models
   for its use cases.

- With the CCAMP WG regarding abstraction of technology specific Data
  Models

- With the PCE WG on uses of a PCE in the ACTN architecture.

- With the IDR WG on the use of BGP-LS in ACTN.

In doing this work, the WG will cooperate with external SDOs as
necessary.

The working group will work on the following items:

- Develop an applicability document based on use cases. This work will
  support the architecture and serve as the repository of requirement
  sets that include: support of APIs/protocols and information models.

- Complete architecture that describes the basic building blocks to
  enable virtual network and service coordination.

- Evaluate gap of existing IETF and other protocols, encoding languages
  and data models to fulfill the requirements. Where the need for data
  models is identified, the working group will first examine data models
  already developed by other working groups.

- Work on data models that are uniquely identified in the scope of ACTN.
  It is envisioned to work on issues of security, privacy, and trust in
  mechanisms that provide abstraction across domain boundaries
 (and therefore across trust boundaries) and the abstraction of
  customer's service-specific models.

- Develop protocol extensions as deemed necessary to support unique
  requirements of controller interfaces.

Milestones

May 2015   Adopt the WG draft on the Applicability of ACTN.
Aug 2015   Adopt the WG draft on the ACTN Architecture.
Sep 2015   Adopt the WG draft on Gap Analysis and YANG models.
Nov 2015   Adopt the WG drafts on Protocol Extensions for basic models.
Feb 2016   Submit the Applicability of ACTN to IESG as an informational
           RFC.
                      Adopt the WG drafts on Protocol Extensions for advanced
           models.
Apr 2016   Submit the ACTN Architecture to IESG for review as an
           informational RFC.
May 2016   Submit the Gap Analysis and YANG model(s) document to IESG for
           review as Proposed Standards RFC.
Jul 2016   Submit the Protocol Extensions for basic models to IESG for
           review as Proposed Standards RFCs.
Sep 2016   Submit the Protocol Extensions for advanced models to IESG for
           Review as Proposed Standard RFCs.
Nov 2016   recharter or conclude the WG.