Internet DRAFT - draft-huang-intarea-san-framework

draft-huang-intarea-san-framework







INTAREA                                                      D.H. Daniel
Internet-Draft                                                  B.T. Bin
Intended status: Standards Track                         ZTE Corporation
Expires: 8 March 2024                                          D.Y. Dong
                                             Beijing Jiaotong University
                                                        5 September 2023


                    Service Aware Network Framework
                  draft-huang-intarea-san-framework-01

Abstract

   Cloud has been migrating from concentrated center sites to edge nodes
   with responsive and agile services to the subscribers.  This
   industry-wide trend would be reasonably expected to continue into the
   future which would enjoy geographically ubiquitous services.  Rather
   than transmitting service data streams to the stable and limited
   service locations such as centered cloud sites, routing and
   forwarding network will have to adapt to the emerging scenarios where
   the service instances would be highly dynamic and distributed, and
   further more, demand more fine-grained networking policies than the
   current routing and forwarding scheme unaware of service SLA
   requirements.  This proposal is to demonstrate a framework under
   which the above-mentioned requirements would be satisfied.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 8 March 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Daniel, et al.            Expires 8 March 2024                  [Page 1]

Internet-Draft              Abbreviated Title             September 2023


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  SAN framework and its chief components  . . . . . . . . . . .   5
   4.  Layer 4 of SAN framework  . . . . . . . . . . . . . . . . . .   6
   5.  Layer 3 of SAN framework  . . . . . . . . . . . . . . . . . .   7
     5.1.  SAN ingress . . . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  SAN relay . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.3.  SAN egress  . . . . . . . . . . . . . . . . . . . . . . .   8
     5.4.  SAN control plane consideration . . . . . . . . . . . . .   8
       5.4.1.  Centralized control plane consideration . . . . . . .   9
       5.4.2.  Distributed control plane consideration . . . . . . .   9
       5.4.3.  Hybrid control plane consideration  . . . . . . . . .   9
     5.5.  SAN user plane consideration  . . . . . . . . . . . . . .   9
       5.5.1.  SIL encapsulation . . . . . . . . . . . . . . . . . .  10
       5.5.2.  SIL in forwarding and routing network . . . . . . . .  10
       5.5.3.  SIL-based routing . . . . . . . . . . . . . . . . . .  10
     5.6.  Hierarchical service routing architecture . . . . . . . .  11
       5.6.1.  Routing scheme in line with multiple service-related
               resources granularity . . . . . . . . . . . . . . . .  12
       5.6.2.  Two-segment routing and forwarding  . . . . . . . . .  12
       5.6.3.  Cross-domain computing routing and forwarding . . . .  13
       5.6.4.  Service traffic affinity  . . . . . . . . . . . . . .  14
     5.7.  Logical sub-layer of service routing in forwarding and
           routing network . . . . . . . . . . . . . . . . . . . . .  14
   6.  Governance and life cycle of service identification label . .  15
     6.1.  Originality and governance of SIL . . . . . . . . . . . .  15
     6.2.  Life cycle of SIL . . . . . . . . . . . . . . . . . . . .  15
   7.  An example of end-to-end SAN work flow  . . . . . . . . . . .  15
     7.1.  Initiation and maintenance of rendering algorithm in SAN
           system  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     7.2.  Configuration of a rendering algorithm (as SIL-RA) in SAN
           forwarding and routing network  . . . . . . . . . . . . .  17
     7.3.  Publication/Subscription of SIL-RA  . . . . . . . . . . .  17
     7.4.  SIL-RA service data stream treatment at SAN forwarding and
           routing network . . . . . . . . . . . . . . . . . . . . .  17




Daniel, et al.            Expires 8 March 2024                  [Page 2]

Internet-Draft              Abbreviated Title             September 2023


       7.4.1.  SIL-RA service data stream treatment at SAN
               ingress . . . . . . . . . . . . . . . . . . . . . . .  18
       7.4.2.  SIL-RA service data stream treatment at SAN relay . .  18
       7.4.3.  SIL-RA service data stream treatment at SAN egress  .  18
     7.5.  SIL-RA service data stream treatment at cloud site  . . .  18
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  19
   11. Informative References  . . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   When it comes to user data security and service responsiveness, it’s
   imperative to migrate the cloud services and resources to the
   locations with good proximity to the users who could reside anywhere
   and launch service requests at any time in the ongoing and upcoming
   industry scenarios.  Therefore, the cloud services and resources has
   been and would continue to be deployed in such a distributed way that
   the services would be ubiquitous, and scheduled and requested
   dynamically by various subscribers.  Cloud and networking services
   and resources operate more coherently with each other as more and
   more services migrate into cloud.  Network has to without gap delay
   adapt as the cloud shift into a new distributed architecture.  The
   same service could be instantiated at multiple locations with
   different networking and computing resources which would be updated
   dynamically.  Under this circumstance, the best service quality
   should be guaranteed by both fine-grained networking and computing
   policies.

   This proposal introduces a light-weight service identification label
   as an index in the user plane to enable the network to be highly
   effectively aware of the dynamic requirements of various cloud
   applications.  The service identification label is designed to
   purport to the fundamental and common services for which the service
   qualities should be guaranteed by both fine-grained networking and
   computing resources.  Combined with an enhanced control plane, a
   logical sub-layer of service function has been employed in this
   framework to enable the network respond to the application’s
   networking and computing demands in a more fine-grained and
   intelligent way, which would bring significant benefits to all
   parties involved in the network and cloud ecosystem while ensure the
   framework to be compatible with the ongoing network architecture.








Daniel, et al.            Expires 8 March 2024                  [Page 3]

Internet-Draft              Abbreviated Title             September 2023


1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Terminology

   *  SAN.  Service Awareness Network

   *  SIL.  Service Identification Label, a light-weight label designed
      to indicate the fundamental and common service types

   *  SCMS.  Service Control and Management System, an entity
      responsible for SIL management and controlling which includes
      materializing networking and computing policies in terms of SIL
      and delivering them to the SAN forwarding and routing nodes.

   *  SAN ingress: routing node maintaining computing resource as well
      as service status from remote cloud sites, and executing the
      cross-site routing policies in terms of the aforementioned status
      as well as the identification of computing service.  SAN ingress
      usually resides at the network edge and works as ingress of the
      end to end service flow.

   *  SAN egress: routing node maintaining computing resource as well as
      service status from the geographically local cloud sites and being
      responsible for the last hop of the service flow towards the
      computing service instance in the specific cloud site.  SAN egress
      usually resides at the network edge and works as egress of the end
      to end service flow.

   *  SAN relay: routing node which is optionally aware of computing
      resource and service status . SAN relay usually resides between
      SAN ingress and SAN egress and works as ordinary routing nodes and
      only gets involved in computing delivery when SAN ingress fails to
      do so.  In particular, when an end-to-end networking policy in
      which SAN relay would be required to identify SIL with specific
      routing and forwarding behavior is involved, SAN relay would
      decapsulate and encapsulate SIL and execute the SIL-specific
      policies.

   *  Global Service Resource and Service Status(GSRS) : General cloud
      site status of the service-related resources and service which
      consists of overall resource occupation and types of service
      (algorithms, functions etc.) the specific cloud site provides.
      GSRS is maintained at SAN ingress and expected to remain
      relatively stable and change in slow frequency.



Daniel, et al.            Expires 8 March 2024                  [Page 4]

Internet-Draft              Abbreviated Title             September 2023


   *  Local Service Resource and Service Status(LSRS) : fine-grained
      cloud site status of the service-related resource and service
      which consists of status of each active service instance as well
      as its parameters which could impact the way the instance would be
      selected and visited by SAN egress.  LSRS is maintained at SAN
      egress and expected to stay quite dynamic and change in high
      frequency.

   *  Service Instance(SI): an active instance of a SIL which resides in
      a host usually purporting to a server, container or virtual
      machine.

3.  SAN framework and its chief components

   An host address is request from DNS system to indicate the user’s
   intention of it’s service destination as well as establish a service
   connection under the conventional internet servivce architecture,
   while SAN framework proposes a refined architecture under which
   user’s intention is simply indicated by the service indentification
   label regardless of the actual service destination.  Therefore, the
   center piece of the SAN framework is the light-weight service
   identification label.  SIL should be confined within a limited and
   exhaustive service type space which only covers the indispensable and
   fundamental networking and computing service blocks.  SIL could be
   component service which would be expected to be invoked by multiple
   application parties, or explicitly specified sub-stream of the same
   service data stream.  A Service control and management system (SCMS)
   which could be a standalone or an enhanced version of the existing
   system.  An entity with the authority of service and resource
   provisioning and delivery takes control of registry, publishing,
   authorization, authentication and policing of SIL within a closed
   governance domain.  The life cycle of SIL runs through end user
   client, routing and forwarding network and cloud in terms of the end-
   to-end service process, and will survive in the above-mentioned
   closed governance domain permanently unless it’s withdrawn or updated
   with the new service identification label norms.

   SIL is designed under this reference framework as a sophisticated
   interface between user and service as well as between service and
   network and cloud.  User client requests the service through SIL
   encapsulated in user data packet header with customized networking
   and computing provisioning guaranteed by SAN routing and forwarding
   network which would index SIL with the corresponding networking and
   computing policies and resources configured from SCMS.  Cloud
   governance system takes SIL as a public interface between user client
   and the cloud service provisioning system.





Daniel, et al.            Expires 8 March 2024                  [Page 5]

Internet-Draft              Abbreviated Title             September 2023


   End user subscribes the service from SCMS and service client carries
   on materializing the service by instantiating an SIL into the service
   packet.  Upon arriving at networking edge, SIL is identified and
   further enables the fine-grained networking service and computing-
   based routing and scheduling.  Along the routing path the service
   data stream gets customized treatment in terms of SIL which is
   inherently defined to bo domain independent.  Figure 1 is the
   reference framework of SAN.  SAN domain reaches beyond conventional
   forwarding and routing network with SIL presence in both service
   client and server at end user devices and cloud sites respectively
   which includes layer 4 and layer 3 from a network architecture
   perspective.  Nevertheless, SAN forwarding and routing domain would
   be a predominant part of the entire reference framework.

   +--------------------------------------------------------------+
   |           Service Control and Management System              |
   +----------------------------|---------------------------------+
                                |
   Service Client               |                    Service Server
   +--+               Service connection upon SIL              +--+
   |  |<------------------------|----------------------------->|  |
   |  |                         |                              |  |
   |  |     +-------------------|------------------------+     |  |
   |  |<----|        Service Identification Label        |---->|  |
   |  |     +---|---------------|------------------|-----+     |  |
   |  |         |               |                  |           |  |
   |  |         |               |                  |           |  |
   |  |    +----V------+   +----V------+     +-----V------+    |  |
   |  |--->|SAN Ingress|-->| SAN Relay |---->| SAN Egress |--->|  |
   +--+    +-----------+   +-----------+     +------------+    +--+
     |           | SAN forwarding and routing domain |          |
     |           |<--------------------------------->|          |
     |               Service Identification domain              |
     |<-------------------------------------------------------->|


                                  Figure 1

4.  Layer 4 of SAN framework

   From perspective of layer 4 which builds and maintains the service
   connection for the application, end user quality of experience would
   be significantly increased with a host-address irrelevant connection
   that remains stable regardless of whether or not the application
   server host shifts.  It’s achieved by establishing the layer 4
   connection with SIL which indicates only the service type without
   semantics of server host location.




Daniel, et al.            Expires 8 March 2024                  [Page 6]

Internet-Draft              Abbreviated Title             September 2023


   In particular, SIL could be encapsulated in layer 4 protocol-intact
   way and layer 4 protocol-updated way.  The former entails informing
   the app client of an SIL when it comes to the process of informing it
   of a destination address such as DNS inquiry process.  Therefore,
   layer 4 protocol remains intact by taking SIL as destination address
   and proceeds as usual.  SIL would be identified and treated with
   fine-grained networking and computing policies of which an
   addressable server host address would be selected and encapsulated in
   the out layer routing header by SAN ingress.  A mapping between SIL
   and server host address could be made either by SAN egress or app
   client and server.  So far as the latter is concerned, a dedicated
   sub-layer between layer 4 and layer 3 should be employed to
   encapsulate SIL which is to be used by layer 4 protocol to establish
   the service connection.  The dedicated SIL sub-layer survives through
   end user, SAN network and the cloud, and SAN nodes would index the
   SIL from this sub-layer to execute the fine-grained service treatment
   in terms of both networking and computing policies.

   SIL structure designing as well as the dedicated sub-layer protocol
   specification are out of scope of this proposal.

5.  Layer 3 of SAN framework

   Layer 3 SAN domain is responsible for the fine-grained treatment of
   service flow referenced by SIL in terms of both networking and
   computing requirements.

5.1.  SAN ingress

   SAN ingress extracts SIL from either the destination address field to
   be encapsulated with SIL or the dedicated SIL sub-layer as
   illustrated in section 4, and determines its fine-grained networking
   policy as well as its next hop in light of which cloud site hosts the
   satisfying service node.  Under this particular circumstance, the
   next hop could be either an SAN egress which connects directly to the
   selected remote cloud site or the selected service server within the
   local cloud site.

   Meanwhile, SCMS delivers both fine-grained networking and computing
   policies in terms of SIL to SAN ingress which maps the extracted SIL
   to the corresponding policies and executes them upon the forwarding
   plane.  SCMS could be the combination of computing and networking
   orchestrator and controller which logically should be two standalone
   entities.  The orchestrator part is responsible for the general
   scheduling policies of computing and networking resources, such as at
   which threshold a policy is triggered, while the controller generates
   and delivers the SIL-indexed policies according to the scheduling
   policies from the orchestrator.  Under distributed routing scheme,



Daniel, et al.            Expires 8 March 2024                  [Page 7]

Internet-Draft              Abbreviated Title             September 2023


   the computing and networking policies generated by the protocols
   (such as BGP) within the SAN forwarding and routing node could also
   be part of SCMS logically.

5.2.  SAN relay

   SAN relay is optionally designed to identify SIL and execute the
   according service routing as well as networking policies when SAN
   ingress alone could not do this.  Particularly, SIL-indexed routing
   status would not necessarily be maintained by SAN ingress once and
   all, so SAN relay could play the role of recursive routing table
   query.  Also, SAN relay could coordinate with SAN ingress to execute
   the networking policy in terms of SIL when necessary.  Nevertheless,
   SAN relay could be reduced to an ordinary forwarding and routing node
   without knowledge of SIL when SAN ingress completes the service and
   networking service policies.

5.3.  SAN egress

   When it comes to SAN egress, SIL could be extracted from the
   destination address field when there is a tunnel encapsulation as an
   outside header such as SRH (SRv6 Header), or from the dedicated SIL
   header when the original SIL in the destination address field has
   been replaced with a selected SAN egress address by SAN ingress.  SAN
   egress maps the SIL with the networking and computing policies from
   SCMS and executes them upon the forwarding plane, the next hop would
   be selected through the computing policy as a server hosting the
   service or a proxy of the service.  SAN egress always removes the
   outside tunnel header and terminates the networking policy.

   The networking and computing policy exchange with SCMS follows the
   same process of SAN ingress other than the difference of
   particularity of the policies generated and delivered.

5.4.  SAN control plane consideration

   As the conventional IP routing control plane scheme in place, SAN
   control plane could also be deployed by centralized and distributed
   scheme or combination of both with additional service status as well
   as the polices.  Service-related control plane only has impacts upon
   SAN ingress and egress, and could logically be decoupled from the
   conventional IP control plane.









Daniel, et al.            Expires 8 March 2024                  [Page 8]

Internet-Draft              Abbreviated Title             September 2023


5.4.1.  Centralized control plane consideration

   SIL-centered networking and computing resource and policy generation
   and maintenance is the key feature of SAN control plane.  Networking
   resource and policy generally aligns with the existing scheme other
   than the SIL-centered networking policy is differentiated in a fine-
   grained granularity.  As far as computing resource and policy is
   concerned, LSRS’s volatility makes it infeasible to be maintained and
   controlled in a centralized entity, GSRS is the chief computing
   resource and service status information to be collected and managed
   in the controller with regard to service stream delivery in routing
   network architecture.  Routing and forwarding policies from GSRS
   calculated in the centralized controller apply only to the segment
   between SAN ingress and egress, while the second segment routing
   policy from SAN egress to the selected service instance in the cloud
   site is determined by LSRS at SAN egress.

   Hierarchically centralized control plane architecture would be
   strongly recommended under the circumstances of nationwide networking
   and computing management and scheduling.

5.4.2.  Distributed control plane consideration

   Networking resource is notified and updated through existing
   distributed protocols (BGP/IGP etc.) and the SIL-centered networking
   policy would be formulated as well.  When it comes to computing
   resource, GSRS is updated among the SAN edge routers which have been
   connected in a mesh way that each pair of edge routers could exchange
   GSRS to each other, while LSRS will be unidirectionally updated from
   cloud site to the associated SAN edge router in which LSRS is
   maintained and its update process is terminated.

   Protocol consideration upon which GSRS and LSRS is updated is out of
   the scope of this proposal and will be illustrated in forthcoming
   draft.

5.4.3.  Hybrid control plane consideration

   In terms of the particularity of service-related resource updating
   and notification, it would be more efficient to update the GSRS by a
   distributed way than a centralized way in terms of routing request
   and response in a limited network and cloud domain, but would be the
   opposite case in a nationwide circumstance.  This is how hybrid
   control plane could be deployed in such a scheme that overall
   optimization could be achieved.

5.5.  SAN user plane consideration




Daniel, et al.            Expires 8 March 2024                  [Page 9]

Internet-Draft              Abbreviated Title             September 2023


5.5.1.  SIL encapsulation

   Service identification label is the predominant index across the
   entire SAN framework ranging through user terminal, forwarding and
   routing network and cloud with SIL working as the virtual
   destination.  Data plane determines the routing and forwarding
   orientation with SIL by inquiring GSRS and LSRS at SAN ingress and
   SAN egress respectively.  SIL encapsulation could be achieved by
   extending the existing packet header and also achieved by designing a
   dedicated SIL sub-layer, which along with the specific structure of
   SIL are out of the scope of this proposal and will be illustrated in
   forthcoming draft.

5.5.2.  SIL in forwarding and routing network

   SAN ingress obtains SIL from either the destination address field or
   the dedicated SIL sub-layer of the user packet header explicitly or
   mapping from the traditional 5 tuples implicitly.  Either way SIL
   starts being indexed for networking and computing policies until it
   arrives at SAN egress.  SIL in the dedicated sub-layer would remain
   intact in the user packet header, while SIL in the destination
   address field would remain intact if SAN ingress employs a tunnel
   header or could be replaced with a selected SAN egress address with a
   dedicated SIL encapsulation in extension headers such as DoH, SRH,
   HBH.  In the case of absence of SIL in user packet header, SAN
   ingress would generate and encapsulate SIL in extension headers by
   combination of existing parameters from user packet header such as 5
   tuples etc.  Apart from the networking and computing policy execution
   at SAN ingress and egress, SIL could be ignored by SAN relay and
   without computing state maintenance unless the mapping between SIL
   and GSRS fails or SIL fine-grained networking policy is involved.

5.5.3.  SIL-based routing

   As illustrated in section 3, SIL encapsulated in the headers and
   maintained in GSRS and LSRS indicates an abstract service type rather
   than a geographically explicit destination label, thus the routing
   scheme based upon SIL is actually a two-part and two-layer process in
   which SIL only indicates the routing intention of user’s requested
   service type while routing does not actually materialize in
   forwarding plane and the explicit routing destination of the two
   segments would be determined by GSRS and LSRS respectively.
   Therefore the actual routing falls within the traditional routing
   scheme which remains as they are.







Daniel, et al.            Expires 8 March 2024                 [Page 10]

Internet-Draft              Abbreviated Title             September 2023


   Apart from the indication of service routing intention, SIL could
   also indicates a specific network serivice requirements by
   associating the networking service policy in GSRS which would
   therefore schedule the network resources such as an SR tunnel,
   guaranteed bandwidth etc. at SAN ingress.

   Therefore, GSRS and LSRS in control plane along with SIL
   encapsulation in user plane enables an logical service routing sub-
   layer which is able to be aware of the computing status from cloud
   sites and forward the service flow in terms of networking services as
   well as computing resources.  Nevertheless, this logical sub-layer
   remains predominantly at SAN ingress and egress nodes.  There're
   drafts such as [I-D.liu-dyncast-ps-usecases] and
   [I-D.li-dyncast-architecture] which analyze the benefits of
   computing-based routing and demonstrate an anycast-as-service-
   identification solution.

5.6.  Hierarchical service routing architecture

   In addition to the existing networking resource and status sensing
   scheme, SAN routing and forwarding network is designed specifically
   to enable sensing the service-related resource and service status
   from the cloud sites and routing the service flow according to both
   network and computing metrics as illustrated in figure 2.  The
   architecture is a horizontal convergence of cloud and network, while
   the latter maintains the converged resource status and thus is able
   to achieve an end to end routing and forwarding policy from a
   perspective of cloud and network resource.  PE1 maintains GSRS with a
   whole picture of the multiple cloud sites, and executes the routing
   policy for the network segment between PE1 and PE2 or PE3, namely
   between SAN ingress and egress, while PE2 maintains LSRS with a focus
   picture of the cloud site where S1 resides, and establishes a
   connection towards S1.  S1 is an active instance of a specific
   service type.  On top of the role of SAN egress which maintains LSRS,
   PE2 and PE3 also fulfill the role of SAN ingress which maintains GSRS
   from neighboring cloud sites.  P provides traditional routing and
   forwarding functionality for computing service flow, and optionally
   remains unaware of service-related status.













Daniel, et al.            Expires 8 March 2024                 [Page 11]

Internet-Draft              Abbreviated Title             September 2023


                                                  +----------+      +-------+
                                          +------>|SAN egress|----->|   SI  |
                                          |       +----------+      +-------+
                +-----------+    +-----------+         PE2              S1
                |SAN ingress|--->|  SAN relay|
                +-----------+    +-----------+         PE3              S2
                   PE1                P   |       +----------+      +-------+
                                          +------>|SAN egress|----->|   SI  |
                                                  +----------+      +-------+
                |<--------- Networking domain --------->|<-Computing domain->|


                               Figure 2

5.6.1.  Routing scheme in line with multiple service-related resources
        granularity

   Status updates of service-related resource and service in the cloud
   sites extend in a quite broad range from relatively stable service
   types and overall resource occupation to extremely dynamic capacity
   changes as well as busy and idle cycle of service instances.  It
   would be a disaster to build all of the status updates in the network
   layer which would bring overburdened and volatile routing tables.

   It should be reasonable to divide the wide range of service-related
   resource and services into different categories with differentiated
   characteristics from routing perspective.  GSRS and LSRS correspond
   to cross-site domain and local site domain respectively, and GSRS
   aggregates the service-related resource and service status with low
   update frequency from multiple cloud sites while LSRS focuses only
   upon the status with high frequency in the local sites.  Under this
   two-granularity scheme, service-related routing table of GSRS in the
   SAN ingress remains in a position roughly as stable as the
   traditional routing table, and the LSRS in the SAN egress maintains a
   near synchronized state table of the highly dynamic updates of
   service instances in the local cloud site.  Nonetheless, LSRS
   focusing upon a single and local cloud site is the normal case while
   upon multiple sites should be exception if not impossible.

5.6.2.  Two-segment routing and forwarding

   When it comes to end to end service flow routing and forwarding,
   there is an status information gap between GSRS and LSRS, therefore a
   two-segment mechanism has to be in place in line with the two-
   granularity routing scheme demonstrated in 5.6.1.  As is illustrated
   in figure 3, R1 as ingress determines the specific service flow’s
   egress which turns out to be R2 according to policy calculation from
   GSRS.  In particular, the SIL from both in-band (user plane) and out-



Daniel, et al.            Expires 8 March 2024                 [Page 12]

Internet-Draft              Abbreviated Title             September 2023


   band (control plane) is the only index for R1 to calculate and
   determine the egress, it’s highly possible to make this egress
   calculation in terms of both networking (bandwidth, latency etc) and
   computing requirements.  Nevertheless, the two SLA routing
   optimization could be decoupled to such a degree that the traditional
   routing algorithms could remain as they are.  The convergence of the
   SLA policies as well as the methods to make SAN ingress aware of the
   two SLA would be illustrated by the example work flow of section 7.
   Nevertheless, the specific solution is out of scope of this proposal.


                   +--------+    +--------+    +--------+    +--------+
                   |  GSRS  |--->|        |--->|  LSRS  |--->|   SI  |
                   +--------+    +--------+    +--------+    +--------+
                       R1            R             R2            S1
                   |<---------- GSRS segment ----->|<-LSRS segment--->|


                                  Figure 3

   When the service flow arrives at R2 which terminates the GSRS segment
   routing and determines S1 which is the service instance selected
   according to LSRS maintained at R2.  Again SIL is the only index for
   LSRS segment routing process.

5.6.3.  Cross-domain computing routing and forwarding

   Co-ordinated computing resource scheduling among multiple regions
   which are usually connected by multiple network domains, is an
   important part of intended scenarios with regard to why computing-
   based scheduling and routing is proposed in the first place.  The
   two-segment routing and forwarding scheme illustrated in5.6.2 is a
   typical use case of cross-domain service routing and forwarding and a
   good building block for the full-domain scenario solution.  Service
   status information is brought into network domain to enable the
   latter scheduling routing policies beyond network.  However, a
   particular scheme has to be put in place to ensure mild and
   acceptable impacts upon the ongoing IP routing scheme.  A consistent
   SIL across terminal, network (multiple domains) and cloud along with
   hierarchical SIL-indexed service-related resource and service status
   which corresponds with different network domains, is the enhanced
   full-domain routing and forwarding solution.  Each domain maintains a
   corresponding ervice-related resource and service status at its edge
   node and makes the service-based routing for the domain-specific
   segment which should be connected by the neighboring segments.






Daniel, et al.            Expires 8 March 2024                 [Page 13]

Internet-Draft              Abbreviated Title             September 2023


5.6.4.  Service traffic affinity

   SIL holds the only semantics of the service type that could be
   deployed as multiple instances within specific cloud site or across
   multiple cloud sites, SIL in the destination field is not explicit
   enough for all of the service flow packets to be forwarded to a
   specific host.  Traffic affinity has to be guaranteed at both ingress
   and egress.  Once the egress is determined at SAN ingress, the
   binding relationship between the egress and the service flow’s unique
   identification (5-tuple or other specifically designed labels) is
   maintained and the subsequent flow could be forwarded upon this
   binding table.  Likewise SAN egress maintains the binding
   relationship between the service flow identification and the selected
   service instance.

   Traffic affinity could be guaranteed by mechanisms beyond routing
   layer, but they will not be in the scope of this proposal.

5.7.  Logical sub-layer of service routing in forwarding and routing
      network

   A SIL-indexed networking and computing policy state from SCMS is
   maintained at the control plane in SAN forwarding and routing
   network.  The policy state regulates and guides the forwarding and
   routing behaviors of SAN nodes on the basis of SIL as well as the
   identification of the service stream.  Namely, the fine-grained
   networking and computing policies bring new abilities for forwarding
   and routing network to be highly efficiently aware of the service
   from perspectives of both networking and computing requirements.

   Either SIL is originated from user client or SAN ingress, SIL’s
   presence in the data plane is guaranteed by various encapsulation
   solutions and could be extracted and indexed by any node for
   execution of either networking policy, computing policy or both.

   As for the networking connection services for which only network-
   domain resources would be involved, SIL provides a fine-grained
   interface between network and application which would be unavailable
   otherwise.  Under this particular circumstance, SIL-indexed
   networking policy state maintenance actually aligns perfectly with
   the existing scheme.

   When it comes to the computing services for which both networking and
   computing resources would be involved, SIL is a light-weight index
   for the fine-grained policies, and the particular computing policies
   are clearly decoupled with that of networking policies .





Daniel, et al.            Expires 8 March 2024                 [Page 14]

Internet-Draft              Abbreviated Title             September 2023


   Therefore, a logical SIL sub-layer with both control and data plane
   has been conceptually employed within SAN forwarding and routing
   architecture.  The sub-layer simply delivers the SIL specific
   policies but would leave them for the existing routing layer to
   execute the policies on a basis of service stream and packet.

6.  Governance and life cycle of service identification label

6.1.  Originality and governance of SIL

   SIL is designated to indicate the fundamental and common service
   types, and could be registered from both networking and computing
   domain with regard to networking connection services and
   comprehensive computing services respectively.  The SIL templates
   should be specified by the entity which is both technically able to
   coordinate the SIL-indexed networking and computing resources and
   services, or by public standardization organizations.  SCMS publishes
   the SIL which has been authenticated, authorized and configured with
   networking and computing policies.

   Application developer and operator subscribes SIL from SCMS and
   integrates it into its application system, and the service client
   initiates the service by encapsulating SIL into its IP protocol
   headers.  SIL template specification is out of scope of this
   proposal.

6.2.  Life cycle of SIL

   Upon the registration and publication of the service, SIL is active
   and available through the ecosystem of terminal, network and cloud
   until it’s withdrawn and terminated by SCMS.  Life cycle of SIL would
   not terminate with a specific end of user service, and the same SIL
   could be instantiated by multiple users simultaneously.  SIL renders
   the services as an effective interface between service and network
   which is inherently absent in the decoupled internet protocol system.

7.  An example of end-to-end SAN work flow

   SIL is controlled and managed by SCMS as illustrated in section 6.1,
   therefore SIL subscription and service agreement process between
   service client and SCMS should be finished before the service client
   initiates a service request and starts sending service data stream
   while SIL would be encapsulated in layer 3 header and lives on
   through the service terminal, SAN routing and forwarding network, and
   service server in the cloud site.  An example work flow of cloud game
   application will be demonstrated under SAN reference framework.  From
   networking and computing resource perspectives, rendering algorithm
   of real-time game situation data should be the dominant sub-service



Daniel, et al.            Expires 8 March 2024                 [Page 15]

Internet-Draft              Abbreviated Title             September 2023


   of cloud game application.  The work flow instantiates the mechanism
   under which the rendering algorithm would be materialized by SAN.

7.1.  Initiation and maintenance of rendering algorithm in SAN system

   Rendering algorithm is identified as a fundamental and common service
   which could be invoked by multiple parties, and at least one provider
   has registered to SCMS and has been authenticated and verified by
   SCMS for the service availability.  An SIL might be allocated or
   activated as SIL-RA which should be structured service identification
   specifically and uniquely allocated for the rendering algorithm.

   When it comes to the networking requirements of rendering algorithm,
   SCMS verifies the corresponding networking resource availability as
   well as capability and establishes a comprehensive SLA state for
   rendering algorithm indexed by SIL-RA.

   When a rendering algorithm provider registers/withdraws the rendering
   algorithm service and the corresponding networking resources update
   to a degree the service would not be able to be rendered as promised,
   the computing and networking SLA state of SIL-RA should be updated
   accordingly.  The signal as well as data stream of SIL-RA is
   illustrated as an example work flow in figure 4.

   +--+    L4:SIL(rendering algorithm)-based service connection  +--+
   |  |<-------------------------------------------------------->|  |
   |  |      +-------------------------------------------+       |  |
   |  |<=====|                  SCMS                     |======>|  |
   |  |      +-#------------------#--------------------#-+       |  |
   |  |        #                  #                    #         |  |
   |  |        #                  #                    #         |  |
   |  |      +-v---------+     +--V------+      +------V---+     |  |
   |  |----->|SAN Ingress|---->|SAN Relay|----->|SAN Egress|---->|  |
   +--+      +-----------+     +---------+      +----------+     +--+
   Service Client                                       Service Server
   ------------->     ===============>          ###############>
   service flow      SIL management flow      SIL policy config flow


                                  Figure 4

   The service client launches a cloud game application request to the
   designated server in a centered cloud site, and a cloud game service
   connection thus would be established, while the rendering algorithm
   might be deployed in the edge cloud nodes for the sake of
   responsiveness of the game service.





Daniel, et al.            Expires 8 March 2024                 [Page 16]

Internet-Draft              Abbreviated Title             September 2023


7.2.  Configuration of a rendering algorithm (as SIL-RA) in SAN
      forwarding and routing network

   End-to-end latency determines both the user experience and the
   feasibility of the service deployed in the cloud site.  The latency
   resulting from the service server and the network path depends on the
   rendering algorithm capability along with the computing resources and
   the networking delay respectively.  Therefore, SCMS maps a networking
   connection policy with 10 mini-seconds of latency and computing
   policy with GPU to SIL-RA, and makes the networking and computing
   policies configuration to the SAN forwarding and routing nodes such
   as SAN ingress, SAN relay and SAN egress through network management
   and control interfaces.

7.3.  Publication/Subscription of SIL-RA

   Upon completion of SIL-RA initiation and configuration, SIL-RA is
   ready to be published to and subscribed by all of the interested
   parties.  The SIL-RA publish/subscribe process is more of a
   commercial agreement than a technical exchange process.  The
   rendering algorithm service client initiates the service by sending
   the service requests as well as data stream with SIL-RA encapsulated
   in layer 3 header.  The rendering algorithm service connection would
   be based soly upon SIL-RA which could be indexed and mapped to a
   computing node located in other edge cloud site, and thus the actual
   service connection could be different from that of cloud game
   application connection as illustrated in section 7.1.

7.4.  SIL-RA service data stream treatment at SAN forwarding and routing
      network

   In the ongoing process of the real-time cloud game service, the
   rendering algorithm service would be invoked simultaneously during
   the entire life-cycle of the game service.  Therefore, the rendering
   algorithm would not be invoked as the initiation of the game service
   and would also not reside in a same cloud site of the master game
   service.  The rendering algorithm service should be specifically
   guaranteed by SAN with comprehensive networking and computing
   policies configured for it.  The game service client would initiate
   an independent rendering algorithm service by encapsulating SIL-RA in
   the data packet headers.










Daniel, et al.            Expires 8 March 2024                 [Page 17]

Internet-Draft              Abbreviated Title             September 2023


7.4.1.  SIL-RA service data stream treatment at SAN ingress

   Upon arrival of SIL-RA service data stream, SAN ingress extracts SIL-
   RA from the designated field of layer 3 header and identifies the
   type of the SIL-RA.  SIL-RA availability as well as the supporting
   computing resources among multiple servers has been maintained in the
   service routing table, the SAN egress connecting to a proper SIL-RA
   server would be selected.

   As configured in 7.3, SIL-RA service stream should be transmitted by
   a forwarding and routing policy with 10 mini-seconds latency between
   SAN ingress and the selected SAN egress.  The SIL-RA service data
   stream would be guided into a designated networking path.  As far as
   bounded latency of routing network is concerned, a path-specific flow
   label could be employed in line with the underling networking
   technologies such as Detnet.

7.4.2.  SIL-RA service data stream treatment at SAN relay

   SIL-RA service data stream treatment with SIL-RA involved is actually
   optional, it’s only necessary when SAN ingress relays the SIL-RA
   service routing request to a SAN relay where the SIL-RA indexed
   service routing table is homed or one or more SAN relay nodes has to
   be involved to provide SIL-RA specific networking connection service.

7.4.3.  SIL-RA service data stream treatment at SAN egress

   As illustrated in section 5.5, SIL-RA indexed service routing table
   would be aggregated with two class granularity at SAN ingress and SAN
   egress respectively.  So SIL-RA would be extracted from the
   designated field and mapped with the LSRS table.  The final hop
   purporting to the selected rendering algorithm service server would
   be determined by SAN egress and the service data stream would be
   forwarded to the server or the server’s proxy accordingly.

   SAN egress should be the terminating node of the networking
   connection path and the the associated path header would be removed.

7.5.  SIL-RA service data stream treatment at cloud site

   SIL-RA encapsulation in layer 3 header would remain intact until the
   data packet arrives at the cloud site.  SIL-RA would be identified
   and treated as both a service connection ID by the rendering
   algorithm server and a rendering algorithm to be guided and scheduled
   by the cloud system respectively .






Daniel, et al.            Expires 8 March 2024                 [Page 18]

Internet-Draft              Abbreviated Title             September 2023


8.  Acknowledgements

   To be added upon contributions, comments and suggestions.

9.  IANA Considerations

   This memo includes no request to IANA.

10.  Security Considerations

   SIL employment in SAN framework would bring security challenges for
   user and application in the cloud sites as well as SAN forwarding and
   routing network.  SCMS is responsible for registry, authorization and
   authentication of SIL and acts as the first check point for SIL.  The
   detailed specification of the security process of SCMS is out of
   scope of this proposal.  When it comes to SAN forwarding and routing
   network, it’s imperative for the service gateway to execute security
   policies with regard to SIL and the specific security solution would
   be illustrated in a dedicated proposal.

11.  Informative References

   [I-D.li-dyncast-architecture]
              Li, Y., "Dynamic-Anycast Architecture", February 2021,
              <https://datatracker.ietf.org/doc/draft-li-dyncast-
              architecture/>.

   [I-D.liu-dyncast-ps-usecases]
              Liu, Peng., "Dynamic-Anycast (Dyncast) Use Cases and
              Problem Statement", February 2021,
              <https://datatracker.ietf.org/doc/draft-liu-dyncast-ps-
              usecases/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Authors' Addresses

   Daniel Huang
   ZTE Corporation
   Nanjing
   Phone: +86 13770311052
   Email: huang.guangping@zte.com.cn






Daniel, et al.            Expires 8 March 2024                 [Page 19]

Internet-Draft              Abbreviated Title             September 2023


   Bin Tan
   ZTE Corporation
   Nanjing
   Phone: +86 13918622159
   Email: tan.bin@zte.com.cn


   Dong Yang
   Beijing Jiaotong University
   Beijing
   Email: dyang@bjtu.edu.cn








































Daniel, et al.            Expires 8 March 2024                 [Page 20]