Subject: [Actn] Definition of "Transport Network" and requirements within the context of ACTN

From: "King, Daniel" <[email-masked]>
Date: Thu, 5 Dec 2013 20:57:09 +0000

Hi All,

During the ACTN bar-BoF in Vancouver (IETF88) there was some discussion on the where we would apply ACTN, specifically which layer and subsequent technologies should be targeted/supported. Let's start with a few clarifications:

- By "transport network" do we mean server network that provides connectivity for higher-layer packet networks, clients and applications.

- A number of server network technologies exist at L1, L2, L3.

- Typically these server networks are run evenly to minimise operational overhead, but lack flexibility/adaptability and dynamic integration with client layers/interfaces/applications.

Now let's review some high-level design goals:

- ACTN interfaces with clients/applications (Data Centers, Virtual Network Operators, et al.) to allow dynamic/automated connectivity and bandwidth request setup.

- ACTN provides an abstracted view of the network resources, i.e., the client/application is agnostic of the underlying technology used within the transport layer.

- ACTN should facilitate the slicing (allocation) of resources, for specific client interfaces and applications. The abstracted topology should also be flexible (adaptable), and support adaptation as client/application bandwidth and connectivity requirements may change.

Therefore, should we categorize ACTN transport networks as being Connection Orientated (CO) and Traffic Engineered (TE):

- Connection Oriented Circuit Switched (CO-CS) & Traffic Engineered (TE)

- Connection Oriented Packet Switched (CO-PS) & Traffic Engineered (TE)

And, do we exclude:

Connection-less Packet Switched (CL-PS)?
When we investigate and document use cases (technology or application specific) might we then focus discussions on ACTN supporting the following technologies:

- WSON
- OTN
- MPLS-TP
- MPLS-TE

And what about:

- OpenFlow (?)
- ForCES (?)
- Segment Routing (?)

Also, would we need to define a new method, for resource description and resource abstraction for each technology. Or reuse something (information and data models) that already exist?

Finally, do we discuss multi-layer scenarios with ACTN providing the capability for a client/application to view/use a topology, and also request adaptations that are comprised of multiple layers? My concern is that the we do not make the problem/solution search space too wide. At the same time, we need to make sure that the ACTN problem statement and proposed Charter includes near-term, and longer-term requirements.

Br, Dan.

---

From: Leeyoung <[email-masked]>
Date: Fri, 6 Dec 2013 15:54:17 +0000

Hi Dan,

I think this is very useful discussion. Here's my comment inline.

Thanks.
Young

From: ACTN [mailto:[email-masked]] On Behalf Of King, Daniel
Sent: Thursday, December 05, 2013 2:57 PM
To: [email-masked]
Subject: [Actn] Definition of "Transport Network" and requirements within the context of ACTN

Hi All,

YOUNG>> Yes. The abstracted topology has two types generally speaking: (i) network-wide abstracted topology and (ii) client-specific abstracted topology. The former one is for general usage to include all end-points of the network similar to ALTO topology map. Of course, the abstracted topology can have a graph form to give a bit more detail than just giving a tunnel view. The latter one is specific to the client in terms of a set of limited client-end points, client's objective function (this means client has a certain service objective such as delay, bandwidth, reliability of paths, etc) as well as the abstraction level. Some client may want to see just a tunnel view (similar to ALTO topology map) while other clients may want to see more detail than a tunnel view.

YOUNG>> Basically, the interface facing clients should be able to support this programmable aspects of the client-specificity. As you said, this interface and abstracted topology should be flexible/adaptable and there should a mechanism to support changes to topology from physical to abstracted. This interaction makes this work very interesting, I think.

YOUNG>> I think this is a good starting point. The underlying transport networks should be able to "guarantee" network resource committed to the client when client makes use of them. From that angle, TE-based transport networks make sense as a starting point. Also when network releases abstract topology to the clients, the link characteristics should tell some resource information about the network. TE-metric is a good way to say that.

And, do we exclude:

- WSON
- OTN
- MPLS-TP
- MPLS-TE

And what about:

- OpenFlow (?)
- ForCES (?)
- Segment Routing (?)

YOUNG>>  As long as any of these can support traffic engineering principle, we can include them, especially SR. I am not sure OF and ForCES as they are just protocols, not data plane technologies.

YOUNG>> There is some work in ALTO area based on JSON encoding. If we can re-use some existing framework.

YOUNG>> I agree.

Br, Dan.

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 9 Dec 2013 04:02:38 +0000

Hi Young,

(snip)

[DD] Is (i) network-wide abstracted topology in scope of ACTN? Do you have some use-case in mind for this?
Conceptually I think (i) is just a special case of (ii) with all end-points in network and no specific constraints.

(snip)

Regards,
Dhruv

---

From: Leeyoung <[email-masked]>
Date: Mon, 9 Dec 2013 16:23:12 +0000

Hi Dhruv,

What I was envisioning on a network-wide abstracted topology is a repository of the baseline network resource view which derives from physical network resource view. As you said, there is no specific constraints on this topology with all end-points.

Perhaps, client-specific abstracted topology is a special of this general network-wide abstracted topology.

>From this network-wide abstracted topology, each client-specific abstracted topology is derived. As network resource is sliced to the list of clients, this network-wide abstracted topology is updated so that it gives the holistic network resource availability.

If the client is a packet network administration/controller which  has the same administrative domain as the optical transport network, then the packet network administrator may want inquire the network-wide abstracted topology for its operation.  There may be other cases where this network-wide abstracted topology may be useful to share under policy and security constraints.

Please note that this network-wide abstracted topology is different from a physical network topology. The virtual network controller needs to maintain this "master" DB to administer its virtual network control capability to its clients.

Regards,
Young

From: Dhruv Dhody
Sent: Sunday, December 08, 2013 10:03 PM
To: Leeyoung; King, Daniel; [email-masked]
Subject: RE: Definition of "Transport Network" and requirements within the context of ACTN

Hi Young,

(snip)

(snip)

Regards,
Dhruv