Subject: [Actn] charter v1.1

From: Leeyoung <[email-masked]>
Date: Thu, 6 Mar 2014 10:18:25 +0000

Hi,
Here's updated charter statement. Take a look and give your comments to the list. Thanks.
Regards,
Young
-----------------------------------------------------------------------------------------------------------------
Draft Charter V1.1 - Abstraction and Control of Transport Networks (ACTN) (3/6/2014)
Previously transport networks were typically static, lacked flexibility, and required long planning times when deploying new services. Network Providers and Service Providers have embraced technologies that allow separation of data plane and control plane, distributed signaling for path setup and protection, and centralized path computation for service planning and traffic engineering. Although these technologies provide significant benefits, they do not meet the growing need for network programmability, automation, resource sharing, and service elasticity necessary for meeting customer demands and evolving Internet applications.
As transport networks evolve, the need to provide network abstraction has emerged as a key requirement for operators. Traffic Engineering (TE) technologies exist per domain (technology or administrative) but infrastructure providers may be unwilling or unable to disclose full TE attributes and topologies. Therefore, it would be beneficial to abstract the TE information exposed when computing end-to-end services,  combined with virtualization of network resources so that the network may be "sliced" and "abstracted" for different uses, applications and services. With customers being provided a portion of the total network resource based on their client or application requirements, with each slice existing independently of each other but operating within the bounds of the entire underlay network.
Augmenting existing TE technologies with network resource abstraction and slicing, available via well-defined customer interfaces, would provide the capabilities to meet the growing demands for network automation, flexibility, programmability and resource sharing for customers and applications. The work effort investigating this problem space is known as Abstraction and Control of Transport Networks (ACTN).
Abstraction and Control of Transport Networks (ACTN) defines new methods and capabilities for the deployment and operation of transport network resource. These are summarized as:
     - Abstraction of the underlying network resources to higher-layer applications and users (customers);
     - Slicing infrastructure to connect multiple customers to meet specific application and users requirements;
     - A computation scheme, via an information model, to serve various customers that request network connectivity and properties associated with it;
     - A virtual network controller that adapts customer requests to the virtual resources (allocated to them) to the supporting physical network control and performs the necessary mapping, translation, isolation and security/policy enforcement, etc.;
     - The coordination of the underlying transport layers/domains and presentation as a consolidated abstract topology to the customers via open and programmable interfaces.
The overall goal of enabling network abstraction and multiple concurrent virtual networks to coexist together on a shared physical infrastructure, comprised on multiple physical layers, and may be subdivided into several smaller objectives. The ACTN effort should utilize existing physical layer monitoring capabilities, algorithmic representation and modeling of physical layer resources to consider transport appropriate metrics and constraints. Moreover, the model may want to support dynamic collection of the statistics (i.e., status and availability) of the underlying transport network infrastructure.
The ACTN working group will produce an architecture for network abstraction and control that facilitates seamless vertical service orchestration across customers, service providers and network infrastructure providers as well as a horizontal E2E service orchestration across multi-domain networks. It will identify key building components and its interfaces amongst these components and include the necessary protocols or protocol extensions to support necessary capabilities, as well as mechanisms for synchronizing traffic resource information across physical network infrastructure, abstracted network infrastructures and customer infrastructure within the confines of security and policy in place.

The WG will examine existing information/data models that allow topology abstraction if there is a need for additional features specific to transport networks before defining new information/data models.

The working group will examine what information needs to be gathered from the transport network and how that information may be abstracted and available to the components of ACTN architecture. The working group will closely consider and address operations, management and security implications when documenting these deliverables.

Specifically, the ACTN WG would be chartered to deliver the following:

1.      Problem Statement: This document will provide a summary of the problem space to be addressed by the ACTN working group including example high-level design principles and requirements.

2.      Framework: This document will provide various aspects of architecture models including business model. computation model, control and interface model as well as high-level design principles/requirements of ACTN addressing network security, privacy and isolation, scalability, manageability and orchestration, programmability and network stability.

3.      Use-cases: These documents will provide various use-cases of ACTN. Among the use-cases that will be developed are Packet Optical Integration (POI), Data Center Interconnect (DCI), and Service Provider interaction with Network Infrastructure Provider, Dynamic Service Control and Monitoring among others.

4.      Requirement: A document will be developed to describe detailed requirements for control mechanisms including messages, conveying information across key entities of the ACTN architecture. All protocol extension work resulting from these requirements should be evaluated if protocols can be modified in coordination with existing working groups at least in part, or may be done in this working group.

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 6 Mar 2014 10:54:52 +0000

Hi Young,

Here are some more changes/comments in the word document (track changes on).
Hopefully they are helpful.

Dhruv

On Thu, Mar 6, 2014 at 10:18 AM, Leeyoung <[email-masked]> wrote:

> Previously transport networks were typically static, lacked flexibility,
> and required long planning times when deploying new services. Network
> Providers and Service Providers have embraced technologies that allow
> separation of data plane and control plane, distributed signaling for path
> setup and protection, and centralized path computation for service planning
> and traffic engineering. Although these technologies provide significant
> benefits, they do not meet the growing need for network programmability,
> automation, resource sharing, and service elasticity necessary for meeting
> customer demands and evolving Internet applications.
>
> As transport networks evolve, the need to provide network abstraction has
> emerged as a key requirement for operators. Traffic Engineering (TE)
> technologies exist per domain (technology or administrative) but
> infrastructure providers may be unwilling or unable to disclose full TE
> attributes and topologies. Therefore, it would be beneficial to abstract
> the TE information exposed when computing end-to-end services,  combined
> with virtualization of network resources so that the network may be
> "sliced" and "abstracted" for different uses, applications and services.
> With customers being provided a portion of the total network resource based
> on their client or application requirements, with each slice existing
> independently of each other but operating within the bounds of the entire
> underlay network.
>
> Augmenting existing TE technologies with network resource abstraction and
> slicing, available via well-defined customer interfaces, would provide the
> capabilities to meet the growing demands for network automation,
> flexibility, programmability and resource sharing for customers and
> applications. The work effort investigating this problem space is known as
> Abstraction and Control of Transport Networks (ACTN).
>
> Abstraction and Control of Transport Networks (ACTN) defines new methods
> and capabilities for the deployment and operation of transport network
> resource. These are summarized as:
>
>      - Slicing infrastructure to connect multiple customers to meet
> specific application and users requirements;
>
>      - A computation scheme, via an information model, to serve various
> customers that request network connectivity and properties associated with
> it;
>
>      - A virtual network controller that adapts customer requests to the
> virtual resources (allocated to them) to the supporting physical network
> control and performs the necessary mapping, translation, isolation and
> security/policy enforcement, etc.;
>
>      - The coordination of the underlying transport layers/domains and
> presentation as a consolidated abstract topology to the customers via open
> and programmable interfaces.
>
> The overall goal of enabling network abstraction and multiple concurrent
> virtual networks to coexist together on a shared physical infrastructure,
> comprised on multiple physical layers, and may be subdivided into several
> smaller objectives. The ACTN effort should utilize existing physical layer
> monitoring capabilities, algorithmic representation and modeling of
> physical layer resources to consider transport appropriate metrics and
> constraints. Moreover, the model may want to support dynamic collection of
> the statistics (i.e., status and availability) of the underlying transport
> network infrastructure.
>
> The ACTN working group will produce an architecture for network
> abstraction and control that facilitates seamless vertical service
> orchestration across customers, service providers and network
> infrastructure providers as well as a horizontal E2E service orchestration
> across multi-domain networks. It will identify key building components and
> its interfaces amongst these components and include the necessary protocols
> or protocol extensions to support necessary capabilities, as well as
> mechanisms for synchronizing traffic resource information across physical
> network infrastructure, abstracted network infrastructures and customer
> infrastructure within the confines of security and policy in place.
>
>
>
> The WG will examine existing information/data models that allow topology
> abstraction if there is a need for additional features specific to
> transport networks before defining new information/data models.
>
>
>
> The working group will examine what information needs to be gathered from
> the transport network and how that information may be abstracted and
> available to the components of ACTN architecture. The working group will
> closely consider and address operations, management and security
> implications when documenting these deliverables.
>
>
>
> 1.      Problem Statement: This document will provide a summary of the
> problem space to be addressed by the ACTN working group including example
> high-level design principles and requirements.
>
>
>
> 2.      Framework: This document will provide various aspects of
> architecture models including business model. computation model, control
> and interface model as well as high-level design principles/requirements of
> ACTN addressing network security, privacy and isolation, scalability,
> manageability and orchestration, programmability and network stability.
>
>
>
> 3.      Use-cases: These documents will provide various use-cases of
> ACTN. Among the use-cases that will be developed are Packet Optical
> Integration (POI), Data Center Interconnect (DCI), and Service Provider
> interaction with Network Infrastructure Provider, Dynamic Service Control
> and Monitoring among others.
>
>
>
> 4.      Requirement: A document will be developed to describe detailed
> requirements for control mechanisms including messages, conveying
> information across key entities of the ACTN architecture. All protocol
> extension work resulting from these requirements should be evaluated if
> protocols can be modified in coordination with existing working groups at
> least in part, or may be done in this working group.
>
>
>
> _______________________________________________
> ACTN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/actn
>
>

---

From: Leeyoung <[email-masked]>
Date: Thu, 6 Mar 2014 15:33:38 +0000

Hi Dhruv,

Thanks. Very good comments, here's my comment in the attachment.

Regards,
Young

From: Dhruv Dhody [mailto:[email-masked]]
Sent: Thursday, March 06, 2014 4:55 AM
To: Leeyoung
Cc: [email-masked]
Subject: Re: [Actn] charter v1.1

Hi Young,

Dhruv

On Thu, Mar 6, 2014 at 10:18 AM, Leeyoung <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

_______________________________________________
ACTN mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/actn