Re: [Apn] APN & Service Differentiation

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Zhenbin,

Slide 11 of https://datatracker.ietf.org/meeting/interim-2021-rtgwg-01/materials/slides-interim-2021-rtgwg-01-sessa-apn-problem-statement-02 says:

• Application-aware Networking (APN) is a new framework, where
   - application-aware information (i.e. APN attribute) including APN identification (ID)
and/or APN parameters (e.g. network performance requirements) is encapsulated at
network edge devices and carried along with the tunnel encapsulation for the packet
traversing an APN domain
   - to facilitate service provisioning, perform fine-granularity traffic steering and network
resource adjustment

It is not clear to me how/whether what you said in the email below matches the above, so let me just use the above quoted text.

My interpretation is that it focuses on carrying APN attribute in packets through the APN domain and using it to steer traffic. To me that is not necessary - there are existing solutions/framework for marking/mapping/steering traffic.

The following two questions are worth discussing:

1. Whether APN attribute is needed or best way
2. Do we need a WG for the discussions

For #2 above, I believe the problem domain falls right into the scope of IETF network slices. Per https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-03:

   It is intended that IETF Network Slices can be created to meet
   specific requirements, typically expressed as bandwidth, latency,
   latency variation, and other desired or required characteristics.
   Creation is initiated by a management system or other application
   used to specify network-related conditions for particular traffic
   flows.
   ...
   It is also intended that applications and components will be able to
   use these IETF Network Slices to move packets between the specified
   end-points in accordance with specified characteristics.
   ...
   Term "Slice" refers to a set of characteristics and behaviours that
   separate one type of user-traffic from another.  IETF Network Slice
   assumes that an underlying network is capable of ...
   fulfilling all or some of SLOs to
   all of the traffic in the slice or to **specific flows**.

It also says the following about IETF Network Slicing Controller:

   o  Provides "Mapping Functions" for the realization of IETF Network
      Slices.  In other words, it will use the mapping functions that:

      *  map technology-agnostic NBI request to technology-specific SBIs

      *  map filtering/selection information as necessary to entities in
         the underlay network.

   o  Via an SBI, the controller collects telemetry data (e.g., OAM
      results, statistics, states, etc.) for all elements in the
      abstract topology used to realize the IETF Network Slice.

   o  Using the telemetry data from the underlying realization of a IETF
      Network Slice (i.e., services/paths/tunnels), evaluates the
      current performance against IETF Network Slice SLO parameters and
      exposes them to the IETF Network Slice customer via the NBI.  The
      NSC NBI may also include a capability to provide notification in
      case the IETF Network Slice performance reaches threshold values
      defined by the IETF Network Slice customer.

https://www.ietf.org/archive/id/draft-li-apn-problem-statement-usecases-04.txt says:

   6.  Use cases for Application-aware Networking (APN)  . . . . . .  10
     6.1.  Application-aware SLA Guarantee . . . . . . . . . . . . .  10
     6.2.  Application-aware network slicing . . . . . . . . . . . .  11
     6.3.  Application-aware Deterministic Networking  . . . . . . .  11
     6.4.  Application-aware Service Function Chaining . . . . . . .  12
     6.5.  Application-aware Network Measurement . . . . . . . . . .  12

Seems to me that, it's not that network slicing is an APN use case but the other way around - network slicing (especially if you consider slice aggregates in draft-bestbar) can address all APN use cases.

Solutions for IETF network slicing are currently being worked on in TEAS. We should discuss why the solutions that are being put together there can’t cater to the service differentiation requirements of APN, but we don’t need a separate WG for this exercise.

Thanks.
Jeffrey

-----Original Message-----
From: Apn <[e-mail]> On Behalf Of Lizhenbin
Sent: Thursday, July 15, 2021 5:39 AM
To: Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]>; [e-mail]; Tarek Saad <[e-mail]>; Vishnu Pavan Beeram <[e-mail]>
Subject: Re: [Apn] APN & Service Differentiation

[External Email. Be cautious of content]


Hi Jeffery,
Thanks for sharing your thought. Please refer to my following explanation.
I think you misunderstood the scope of APN work. APN work is not about implementing the network service, but focuses on how to map the traffic to the network service.
1) The network service can implement in a granularity level. Mapping to the network service can be implement in another level. For example, you can implement one network slice, but you also need to solve the issue how to map the traffic to the network slice. It can be based on the VPN, the prefix on the prefix of the VPN, or the 5-tuple information of the packet. In section 3 of the draft draft-li-apn-problem-statement-usecases, we discussed the problems of the existing methods of using 5-tuple information to map the traffic to the network service.
2) APN is about how to map the traffic to the network service. More network services besides network slice will be take into account. In section 3 of the draft draft-li-apn-problem-statement-usecases, we talked about the possible network service which can be mapped through APN, including SR path for SLA, DetNet, SFC, network measurement and the network slice. For example, SR path can be setup to guarantee the SLA in the network. The ingress node can also map to the SR policy according to the APN ID.

It is one thing that network service (network slice) can be set up in a granularity. APN is not about setting up the network service in an application-group/user-group level. The possible network service such as SR path and network slice can still setup in its own granularity.
It is one other thing that mapping the traffic to the network service in another granularity. This is the work APN work focus on. Especially, it is very common that the 5-tuple is always adopted to set up the policy to implement the mapping in a fine granularity. APN examines the challenges of the existing methods and propose the new possible work to improve it.


Best Regards,
Robin




-----Original Message-----
From: Apn [mailto:[e-mail]] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Wednesday, July 14, 2021 9:05 PM
To: [e-mail]; Tarek Saad <[e-mail]>; Vishnu Pavan Beeram <[e-mail]>
Subject: Re: [Apn] APN & Service Differentiation

Hi,

To make it easier for commenting, I converted the slides to text.

Thanks.
Jeffrey


Application Aware vs. Service Differentiation, and Scaling

Application-aware Networking
============================

* "application-aware information (i.e. APN attribute) including APN identification (ID) and/or APN parameters (e.g. network performance
requirements) is encapsulated at network edge devices and carried in packets traversing an APN domain in order to facilitate service provisioning, perform fine-granularity traffic steering and network resource adjustment" - draft-li-apn-framework
* Application Information embedded in packets
  - <SLA, App, User, Flow, Performance Parameter>

* Fine-granularity traffic steering

Forwarding Paradigm Evolution
============================

* We have improved scaling by removing per-flow state in networks
  - IntServ+RSVP -> MPLS TE/tunneling -> DiffServ (w/ or w/o TE) -> Segment Routing

* Do we really want to do per-flow fine-granularity steering again?
  - Presumably yes - according to APN proponents
    - Service requirements, especially in 5G environment/era
    - Closed Networks - scale is not a concern
    - Modern routers can scale better than before

* Would a coarser granularity meet the requirements?

* Do we need a new framework/architecture/solution?

Application-aware or Servicedifferentiation?
============================

* Routers should not be application-aware
  - They should not care about <AppID, UserID, FlowID> - that should be opaque info mapped to anpaque number, e.g., a label
  - Performance parameters (BW, latency/delay, jitter, loss) should be mapped to opaque numbers as well, instead of being carried and interpreted as is in packets
    - The only reasonable "raw" parameter is perhaps the "deadline timestamp" that enables transit routers to drop packets that won't meet the delivery deadline - but that is not about "application-aware"

* Routers should be able to offer differentiated services
  - They should care about SLA/PHB (Per Hop Behavior)
    - at fine granularity if so desired

* Solution already exists
  - Diffserv-aware TE: label per <PHB, LSP> ->
  - PHB per slice-aggregate (draft-bestbar-teas-ns-packet)
    - Any granularity level
    - Works with SR, MPLS, IPv6

Slice Aggregates (draft-bestbar)
============================

* "a collection of packets that match a slice policy selection criteria and are given the same forwarding treatment; a slice aggregate comprises of one or more IETF network slice traffic streams; the mapping of one or more IETF network slices to a slice aggregate is maintained by the IETF Network Slice Controller"
* Unit of "slice aggregate" is "a collection of packets" - any level of granularity
  - Some (not necessarily all) streams in a single slice
    - This could be down to an app or flow if needed
  - All traffic in a single or more slices

PHB per Slice Aggregate
============================
* An opaque Slice Selector (SS) is added by ingress node to each packet to identify the slice aggregate that it belongs to
  - Forwarding Address Slice Selector: IP address or label
  - Global Identifier Slice Selector: MPLS or IPv6 flow label

* A transit node uses the SS to associate packets with a slice aggregate and to determine the Slice policy Per Hop Behavior (S-PHB). The Diffserv CS may also be used to apply a Diffserv PHB to differentiate within the same slice aggregate

Slice Aggregates Summary
============================

* An Entire Framework/Solution for Any Granularity Level
  - draft-bestbar-teas-ns-packet - framework/solution
  - draft-bestbar-spring-scalable-ns - for SR networks
  - draft-bestbar-lsr-spring-sa - IGP signaling
  - draft-bestbar-teas-yang-slice-policy - YANG

* Satisfies all requirements in draft-li-apn-framework
* Except the "MPLS/IPv6 encapsulation SHOULD be extended to be able to carry the APN attribute" requirement
  - Because that is an unnecessary requirement
    - existing label/address can be used w/o changes to identify PHB for any granularity level

-----Original Message-----
From: Apn <[e-mail]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Tuesday, July 13, 2021 11:01 AM
To: [e-mail]; Tarek Saad <[e-mail]>; Vishnu Pavan Beeram <[e-mail]>
Subject: [Apn] APN & Service Differentiation

[External Email. Be cautious of content]


Hi,

We would like to share some slides that summarize our view on this topic.

We had planned to write an informational draft that goes along the slidespresent in the upcoming BoF. However, since presentation slots are granted only for drafts/topics that already have some discussions on the mailing list, we decide to just post the slides here to trigger the discussion. Since the information draft would just be along the same lines, we skipped the draft itself - the slides should be enough for the discussion.

Comments are appreciated!

Thanks.
Jeffrey, Tarek, Pavan

Juniper Business Use Only

Juniper Business Use Only

Juniper Business Use Only

--
Apn mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/apn__;!!NEt6yMaO-gk!UqwjVRPal8BWpa-bidCuJj3QNk2uPJ4RdHsO7wZCmyxILGKAL8s1rve9DKjj8B6S$

--
Apn mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/apn__;!!NEt6yMaO-gk!UqwjVRPal8BWpa-bidCuJj3QNk2uPJ4RdHsO7wZCmyxILGKAL8s1rve9DKjj8B6S$

Juniper Business Use Only