Internet-Draft Hybrid-Function-Chain (HFC) Framework September 2024
Yuan, et al. Expires 2 April 2025 [Page]
Workgroup:
RTGWG
Internet-Draft:
draft-yuan-rtgwg-hfc-framework-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
D. Yuan
ZTE Corporation
Y. Zhang
China Unicom
D. Huang
ZTE Corporation
C. Miao
ZTE Corporation

Hybrid-Function-Chain (HFC) Framework

Abstract

With the maturity of cloud native application development, applications can be decomposed into finer grained atomic services. On the other hand, as a distributed computing paradigm, fine grained micro-services could be deployed and implemented in a distributive way among edges to make computing, storage and run-time processing capabilities as close to users as possible to provide satisfied QoE. Under the circumstances analyzed, a Hybrid-Function-Chain (HFC) framework is proposed in this draft, aiming to wisely allocate and schedule resources and services in order to provide consistent end-to-end service provisioning.

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 2 April 2025.

Table of Contents

1. Brief Introduction of HFC

In the context of cloud native, applications are often no longer provided in the form of monolithic services, but are decomposed into a series of cloud native services deployed in distributed clusters, with inter-connections and joint provision to the outer side.

Traffic lanes, for instance, have emerged and been commonly used for environmental isolation and traffic control of the entire request chain of services for grayscale publishing scenarios, would be reckoned as a typical example for Hybrid-Function-Chain (HFC). In fact, the creation of traffic lanes is still executed by various existing network API configurations of the cluster. The service routes are always configured in the cluster and identified endpoints under a service name to implement various scheduling strategies and perform load balancing schemes among multiple optional instances.

Edge computing, as a distributed computing paradigm, the core idea is to make computing, storage and service processing as close to the clients and customers as possible to reduce latency, improve response speed and enhance data security. When applications are further deconstructed into atomic services as analyzed previously, service inter-connections MAY not only exist in adjacent clusters deployed in a same edge, but also happen with network paths connecting remote edge data centers. Thus, incremental requirements would be raised correspondingly. Relevant use cases and requirements are discussed in [I-D.huang-rtgwg-us-standalone-sid].

Correspondingly, this draft proposes a Hybrid Function Chain (HFC) architecture aimed at providing end-to-end and consistent service provisioning capabilities which includes multiple service endpoints and corresponding connected network paths. Compared to conventional schemes and patterns, HFC is granted with multiple features and connotations.


              Step 1
               ----
              ( -- )
-----------> ( (  ) )
Request     (   --   )
             -------- \                                  +---+
                       \                                (     )
                        \     Step 2         Step 3  +--       +
                         \     ----                 (           )
                          \   ( -- )               (  --  --     )
                           V ( (  ) )            (   (  )(  )     )
                            (   --   )<--------->(    --  --  ... )
                           / --------             (              )
                          /                        +------------+
                         /
              Step 4    /
               ----    /
              ( -- )  /
<----------- ( (  ) )V
            (   --   )
             --------

                Edge Clusters/Clouds

Figure 1: HFC across Multi-edges

Based on the concepts of HFC proposed here, this draft further analyzes HFC framework and deconstructs it into several planes with incremental functions and features based on conventional network and service mesh techniques.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Terminology

4. Hybrid-Function-Chain (HFC) Framework

Hybrid-Function-Chain (HFC) framework generally includes administration plane, control plane and forwarding plane. Based on conventional framework of network and cloud native practices, several incremental functions and features are added and deployed.


-----------------------------------------------------------------------------
                   +----------+ +-----------+ +---------+
                   | AR/VR/XR | | Metaverse | | ....... |
                   +----------+ +-----------+ +---------+
-----------------------------------------------------------------------------
Administration     +------------------------------------+
Plane              |    Service Analysis & Operation    |
                   +------------------------------------+
                   +------------------------------------+
                   |    Service Evaluation & Modeling   |
                   +------------------------------------+
                   +------------------------------------+
                   | Service Scheduling & Orchestration |
                   +------------------------------------+
-----------------------------------------------------------------------------
Control Plane
+---------------+ +---------------------------------------+ +---------------+
|               | | Service Registration & Administration | |               |
|K8S,           | +---------------------------------------+ |               |
|Service Mesh   | +---------------------------------------+ |               |
|(Istio)        | |    Service Discovery & Publication    | |               |
|               | +---------------------------------------+ |               |
|Galley, Pilot, | +---------------------------------------+ |               |
|Mixer, Citadel | |Service Routes Calculation & Generation| |               |
|               | +---------------------------------------+ |               |
|    Cluster    | +---------------------------------------+ |    Network    |
| Control Plane | |Service Inter-connection Configuration | | Control Plane |
+---------------+ +---------------------------------------+ +---------------+
-----------------------------------------------------------------------------
Forwarding        +---------------------------------------+
Plane             | Service Identification Administration |
                  +---------------------------------------+
                  +---------------------------------------+
                  |     Service Aware Traffic Steering    |
                  +---------------------------------------+
                  +---------------------------------------+
                  | Service Provisioning & Observability  |
                  +---------------------------------------+
-----------------------------------------------------------------------------

Figure 2: HFC Framework

4.1. Administration Plane

Service Analysis and Operation: The increasingly complex and diverse applications and services display different characteristics and features for outer users. In terms of orchestration for distributed micro-services, Service Analysis and Operation interprets the external and internal forms of overall applications and services as corresponding deconstruction patterns.

The above deconstructed microservices have serial, parallel, unidirectional, and bidirectional relationships, and their interconnection and collaboration are comprehensively presented as user and outer oriented applications.

Service Evaluation and Modeling: There are different and various resource requirements raised by multiple microservices, including but not limited to:


   ----                   ----
  ( -- )                 ( -- )
 ( (  ) )-------------->( (  ) )
(   --   )             (   --   )
 --------               --------
Notification
   ----                   ----
  ( -- )                 ( -- )
 ( (  ) )<------------->( (  ) )
(   --   )             (   --   )
 --------               --------
Request and Response
   ----                   ----
  ( -- )                 ( -- )
 ( (  ) )-------------> ( (  ) )
(   --   )     \       (   --   )
 --------       \       --------
                 \
                  \       ----
                   \     ( -- )
                    --->( (  ) )
                       (   --   )
                        --------
One-to-Many
        +---+
       (     )
    +--       +
   (           )
  (  --     --  )
(   (  )-->(  )--)------->
(    --     --   )
 (              )
  +------------+
Successive Services at same Location

Figure 3: Inter-Connection between Services and Functions

Service Orchestration and Scheduling: Service administration would customize strategies or specific algorithms depending on circumstances of infrastructure and required proposals. Providing low-latency experiences or achieving load balance among available instances and resources SHOULD be selected as specific inclinations for further scheduling.

4.2. Control Plane

Service Registration and Administration: Based on the results and conclusions analyzed by Service Analysis and Operation, the overall service and included micro-services MAY be represented and administered by corresponding identifications. In this draft, Service IDs for micro-services and HFC IDs for HFC processes and services are generally defined. Therefore, HFCs and corresponding micro-services would be displayed and labeled in the control plane. Appropriate identifications would facilitate indicating the service traffic of the workflow.


               ----
              ( -- )
-----------> ( (  ) )
            (   --   )    HFC ID,
             -------- \   Service 1(Pre)
             Service 1 \  Service 2(Next)
                        \
                         \     ----                 ----
                          \   ( -- )               ( -- )
                           v ( (  ) )             ( (  ) )
                            (   --   )<--------->(   --   )
                           / --------             --------
                          /  Service 2            Service 3
                         /
                        /
               ----    /  HFC ID,
              ( -- )  /   Service 2(Pre)
<----------- ( (  ) )v    Service 4(Next)
            (   --   )
             --------
             Service 4


Figure 4: Service Administration by Identification

Service Discovery and Publication: Depending existing and mature control plane protocols and interfaces, distributed services and capabilities of infrastructures SHOULD be able to be collected. Relevant schemes include extended IGP, BGP, BGP-LS, RESTful, Telemetry. The information learned in the control plane MAY include:

Service Routes Calculation and Generation: Based on the information collected in Service Discovery and Publication, service routes would be calculated to determine appropriate instances and forwarding paths. Service Routes Calculation and Generation SHOULD follow the intentions identified in Service Orchestration and Scheduling. According to Service Registration and Administration, service routes could be distributed and indexed by HFC and service identifications.

Service Inter-connection Configuration: Within conventional schemes for services inter-connection, configurations would be disposed for endpoints distributed in multiple clusters. Istio, for instance, replys APIs including ServiceEntry, VirtualService and DestinationRules to describe inter-connections and relevant principles. Considering the framework of HFC proposed in this draft, service routes would be translated into corresponding configurations issued to clusters for revising API files.

4.3. Forwarding Plane

Service Identification Administration: Traffic would be able to be steered according to identifications distributed from the control plane. Also, the service identifications would inherit and re-generate from the previous ones in the workflow. Proxies, sidecars or gateways SHOULD be able to administer the inheritance and renewal relationship. Suppose an HFC application includes Service ID 1, ID 2 and ID 3, an identifier of {HFC, Service ID 2} implies that the successive function is expected to be Service ID 3. Correspondingly, the identifier would be modified as {HFC, Service ID 3}.

Service Aware Forwarding: Service routes entries would be distributed from the control plane and involved entities and devices would perform traffic forwarding accordingly. Relevant entries include:

Service provisioning and observability: By implementing and performing OAM or APM schemes, forwarding plane would monitor the circumstances and performance of traffic flows. With detections of failures and possible degradations, forwarding plane would be able to support recovering, enhancing and provisioning for traffic flows.

5. SRv6-based HFC Implementation

Based on SRv6, forwarding paths orchestrated for an end-to-end HFC service including specific implementations would be able to be encoded in an SRH, in order to achieve consistent service provisioning across multiple endpoints deployed in distributed clusters and even edge clouds.

The overall paths would be explicitly indicated in the Segment List or be generally displayed. Correspondingly, a strict mode and a loose mode are proposed in this draft.


                                    Service A Ins,Proxy
                                            +---+
                                           (     )
                                        +--       +
                                       (           )
                                      (  --     --  )
                                    (   (  )---(  )  )
                                    (    --     --   )
                                     (              )
+-----------+                         +------------+
|           |                                |
|Application|                           +--------+
|           |      +--------------------|HFC GW A|
|    GW     |     /                     +--------+
|           |    /                           |
+-----------+   /   --------------+          |
      |        /                   \         |
      |       /                     +        |
      |      /                      |        |
      |     /                       |        |                 +---+
      |    /                        |        |                (     )
      |   /                         |        |             +--       +
      |  /                          |        |            (           )
      | /                           |        |           (  --     --  )
  +--------+                        |   +--------+     (   (  )---(  )  )
  | HFC GW |                        |   |HFC GW B|-----(    --     --   )
  +--------+                        |   +--------+      (              )
        \                           +       /            +------------+
         \                         /       /           Service B Ins,Proxy
          \                       /       /
           \                     /       /
            \                   /       /
             \                 /       /
              \     <---------+       /
               \                     /
                \               +--------+      HFC Service
                 +--------------|HFC GW C|      Operation Domain
                                +--------+
                                     |
                                   +---+
                                  (     )
                               +--       +
                              (           )
                             (  --     --  )
                           (   (  )---(  )  )
                           (    --     --   )
                            (              )
                             +------------+
                           Service C Ins,Proxy

Figure 5: HFC Domain and end-to-end Delivery

In the above SRv6 based HFC implementation, several SRv6 SIDs MAY be generally defined in this draft:



   +--------+          X      +---------+
   |HFC GW A|-----------------|HFC GW B1|
   +--------+ --------------- +---------+

   backup path

Service A Ins,Proxy
        +---+
       (     )
    +--       +
   (           )
  (  --     --  )
(   (  )---(  )  )                                     +---+
(    --     --   )                                    (     )
 (              )                                  +--       +
  +------------+                                  (           )
         |                                       (  --     --  )
    +--------+                X+---------+     (   (  )---(  )  )
    |HFC GW A|-----------------|HFC GW B1|-----(    --     --   )
    +--------+ -----------+    +---------+    / (              )
                           \                 /   +------------+
    backup path             \               /  Service B Ins,Proxy
    and HFC GW               \ +---------+ /
    (with same inst)          \|HFC GW B2|/
                               +---------+

Service A Ins,Proxy
        +---+
       (     )
    +--       +
   (           )
  (  --     --  )
(   (  )---(  )  )                                      +---+
(    --     --   )                                     (     )
 (              )                                   +--       +
  +------------+                                   (           )
         |                                        (  --     --  )
    +--------+                 +---------+    X (   (  )---(  )  )
    |HFC GW A|-----------------|HFC GW B1|----- (    --     --   )
    +--------+ -----------+    +---------+       (              )
                           \                      +------------+
    backup path             \                     Service B Ins 1
    and HFC GW               \ +---------+
    (with different inst)     \|HFC GW B2|\             +---+
                               +---------+ \           (     )
                                            \       +--       +
                                             \     (           )
                                              \   (  --     --  )
                                               \(   (  )---(  )  )
                                                (    --     --   )
                                                 (              )
                                                  +------------+
                                                  Service B Ins 2

Figure 6: HFC Protection

Furthermore, SRv6 based HFC SHOULD support other features. For instance, backup paths would be orchestrated and accordingly configured at HFC GWs. End-to-end service observability would be achieved by distributed tracing and relevant schemes. More detailed implementation designs would be discussed in future works.

6. Security Considerations

TBA.

7. Acknowledgements

TBA.

8. IANA Considerations

TBA.

9. Normative References

[I-D.huang-rtgwg-us-standalone-sid]
Huang, D., Liang, J., Yang, F., Zhang, Y., and D. Yang, "Use Cases-Standalone Service ID in Routing Network", Work in Progress, Internet-Draft, draft-huang-rtgwg-us-standalone-sid-01, , <https://datatracker.ietf.org/doc/html/draft-huang-rtgwg-us-standalone-sid-01>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

Dongyu Yuan
ZTE Corporation
Nanjing
China
Yan Zhang
China Unicom
China
Daniel Huang
ZTE Corporation
Nanjing
China
Chuanyang Miao
ZTE Corporation
Nanjing
China