Re: [Apn] APN & Service Differentiation

[Lizhenbin <[e-mail]>]

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://www.ietf.org/mailman/listinfo/apn