Subject: [Actn] Abstraction and Control of Transport Networks ACTN

From: Diego Caviglia <[email-masked]>
Date: Fri, 6 Dec 2013 11:58:43 +0000

Hi all
           Some comments to the Dan list.

Ciao

D

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.
[DC] Yes I think is a good definition; we need to promote this a little bit if we would include L3, usually when someone says Transport people think to L0/1
- A number of server network technologies exist at L1, L2, L3.
[DC] hmmm I would add L0 say L0=DWDM, L1=TDM Stuff (SDH/SONET/OTN), L2=Eth etc etc, L3=IP/MPLS
- Typically these server networks are run evenly to minimize operational overhead, but lack flexibility/adaptability and dynamic integration with client layers/interfaces/applications.
[DC] hmmmm I would say to lower the cost/bit/Km I would say that are not directly driven by client layers/interface/applications but via intermediate system e.g. NMS or automated control planes but the "trigger" of the set-up is always in the hand of a human been...well always is may be too strong most the time is human but very unlikely is linked to any 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.
[DC] I would add teardown and modification
- 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.
[DC] yes we should define better what we mean with abstract here....won't be easy.
- 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):
[DC] so p2p and p2mp are part of the work but NOT mp2p and mp2mp.  Sounds good
- Connection Oriented Circuit Switched (CO-CS) & Traffic Engineered (TE)
[DC] yes
- Connection Oriented Packet Switched (CO-PS) & Traffic Engineered (TE)
[DC] I think here we'll avoid ATM, PBB-TE etc etc so basically is MPLS(-TP) with RSVP-TE right?
And, do we exclude:
Connection-less Packet Switched (CL-PS)?
[DC] agreed
When we investigate and document use cases (technology or application specific) might we then focus discussions on ACTN supporting the following technologies:
- WSON
[DC] hmmm here WSON is a data plane plus a control plane....i would say DWDM with or without a GMPLS/PCE based control plane
- OTN
[DC] as above with or without a GMPLS/PCE based control plane
- MPLS-TP
[DC] just the data plane here
- MPLS-TE
[DC] as above, do we want to consider also segment routing here?
And what about:
- OpenFlow (?)
- ForCES (?)
- Segment Routing (?)
[DC]- I2RS (?)
[DC]- PCEP (?)
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?
[DC] I think ONF is doing a lot of work here so we should have a look.
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?
[DC] I think this is one of the key point we have to solve and this why I said the abstraction won't be easy

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.
[DC] Yes
Br, Dan.

---

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

Hi Diego,

Great discussion. Please see my comment inline.

Regards,
Young

From: ACTN [mailto:[email-masked]] On Behalf Of Diego Caviglia
Sent: Friday, December 06, 2013 5:59 AM
To: [email-masked]
Cc: King, Daniel ([email-masked])
Subject: [Actn] Abstraction and Control of Transport Networks ACTN

Hi all

Ciao

D

Hi All,
YOUNG>>  "transport network" defined as connectivity for HL packet networks, clients and applications is a good definition, beyond just packet networks. Packet networks themselves can also be a server 'transport network' to clients/applications. In that sense, we have a wider scope of what 'transport network' is. But we have to recognize the nature of applications/clients may differ as to what 'transport' service they choose. For best-effort applications, L3 transport may be adequate; for services/applications needing stringent QoS and resource reservations/guarantee, TE-based transport may be adequate.
The point is that the driver is the requirement of clients/applications.
YOUNG>> This is a good point. There is a need for an intermediate system such as "mediation layer" or "virtualization layer" between client/application and the transport network that can support programmable interfaces. This programmable intermediate system is neither NMS nor automated control planes. This is 'shim' layer that facilitates the activity of NMS or automated control planes.
YOUNG>> Agree. In addition to this, I see the value for monitoring/notification between transport networks and clients/applications.
YOUNG>> Yes, this is one of the most important work items as to how to characterize/define abstraction. There are two issues: (i) how to represent the underlying resource into applications - this is information/data model; (ii) how to efficiently map between physical resources and virtual resources and how accurate the abstraction is --- this is about compute model and algorithm. This aspect is a research item that needs to be worked out in parallel with the info/data model. The compute model and algorithm work is perhaps addressed in SDN RG in parallel to ACTN.
YOUNG>> I agree.
YOUNG>> Yes, we discussed this aspect earlier.