Signaling In-Network Computing operations (SINC) deployment considerations
draft-lou-rtgwg-sinc-deployment-considerations-01

Network Working Group                                             D. Lou
Internet-Draft                                                L. Iannone
Intended status: Experimental                                      Y. Li
Expires: 10 June 2024                                           C. Zhang
                                                                  Huawei
                                                         8 December 2023

      Signaling In-Network Computing operations (SINC) deployment
                             considerations
           draft-lou-rtgwg-sinc-deployment-considerations-01

Abstract

   This document is intended to discuss some deployment aspects of
   "Signaling In-Network Computing operations" (SINC).  Based on some
   examples, this document analyzes how each device in the SINC chain
   undertakes its own functions.  This document showcase the use of SINC
   mechanism.

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 10 June 2024.

Copyright Notice

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

Lou, et al.               Expires 10 June 2024                  [Page 1]
Internet-Draft       SINC deployment considerations        December 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  SINC Deployment Considerations  . . . . . . . . . . . . . . .   3
   4.  SINC over GENEVE Considerations . . . . . . . . . . . . . . .   4
     4.1.  SINC GENEVE encapsulation . . . . . . . . . . . . . . . .   4
     4.2.  SINC over GENEVE Workflow . . . . . . . . . . . . . . . .   4
   5.  SINC over SFC Considerations  . . . . . . . . . . . . . . . .   4
     5.1.  SINC NSH encapsulation  . . . . . . . . . . . . . . . . .   5
     5.2.  SINC over SFC Workflow  . . . . . . . . . . . . . . . . .   6
   6.  SINC over MPLS Considerations . . . . . . . . . . . . . . . .   7
     6.1.  SINC MPLS encapsulation . . . . . . . . . . . . . . . . .   7
     6.2.  SINC over MPLS Workflow . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
   Normative References  . . . . . . . . . . . . . . . . . . . . . .   9
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   "Signaling In-Network Computing operations" (SINC) is a mechanism to
   enable signaling in-network computing operations on data packets in
   specific scenarios like NetReduce, NetDistributedLock, NetSequencer,
   etc.  This mechanism can effectively reduce the task completion time
   and improve the system efficiency.  The SINC framework design can be
   found in [I-D.zhou-rtgwg-sinc-00].

2.  Terminology

   This document uses the terms as defined in [RFC7498], [RFC7665],
   [RFC8300], [RFC3031], [RFC5036] and [RFC2205].  This document assumes
   that the reader is familiar with the Service Function Chaining
   architecture and Multi-Protocol Label Switching architecture.

Lou, et al.               Expires 10 June 2024                  [Page 2]
Internet-Draft       SINC deployment considerations        December 2023

3.  SINC Deployment Considerations

   When deploying the SINC solution in the network, the packets from the
   host needs to be transmitted through a path containing SINC capable
   switches/routers (SW/R) for in-network data computation.  Different
   from the simplistic experimental network environment used for in
   network computing verification in research papers, the real network
   is much more complex, containing multiple SINC SW/Rs with different
   capabilities and multiple paths between sources and destinations, as
   shown in Figure 1.

       +--------+  +--------+
       |  SINC  |  |  SINC  |
       | Node A |  | Node B |
       +--------+  +--------+
          |      \/    |    \
          |     / \    |     \
          |    /   \   |      \
       +-------+    +-------+   +-------+
       | SW/R  |    | SW/R  |   | SW/R  |
       +-------+    +-------+   +-------+
         |             |            |
       +-------+    +-------+       |
       | Proxy |    | Proxy |       |
       +-------+    +-------+       |
         |             |            |
    +---------+   +---------+   +---------+
    | Host A  |   | Host B  |   | Host C  |
    +---------+   +---------+   +---------+

                   Figure 1: SINC In Deployment Topology

   The packets traveling between Host A and Host B may pass SINC Node A
   or SINC Node B via different paths.  It is essential to create a
   proper route with nodes to support SINC operation and facilitate the
   packet delivery.  The SINC capable SW/Rs should periodically
   advertise, to the control plane, their networking & computing
   capacities and capabilities, e.g. the operation it can perform, the
   current work load, the link capacity, etc.  Based on those
   information, the control plane is responsible to create a proper
   route where the data in the packet will undertake the desired
   computation before arriving at the destination host.  Such a path
   could be located at layer 2, 3 or 4 dependent of the network context
   and application environments.  For instance, in a telecommunication
   network where the Multi-Protocol Label Switching (MPLS) [RFC3031] is
   deployed, MPLS can be used to encapsulate the SINC header and deliver
   the packet to a SINC capable SW/R.  In a Data Center Network, if the
   Generic Network Virtualization Encapsulation (GENEVE) [RFC8926] is

Lou, et al.               Expires 10 June 2024                  [Page 3]
Internet-Draft       SINC deployment considerations        December 2023

   applied, It can be used for encapsulation.  Other encapsulation
   protocols like General Routing Encapsulation (GRE) [RFC2784], Service
   Function Chaining (SFC) [RFC7665], and so on, could be potential
   candidates as well.  The SINC header is usually copied/moved right
   after the new encapsulation header, which makes it easier to access
   the SINC header.

4.  SINC over GENEVE Considerations

   TBC

4.1.  SINC GENEVE encapsulation

   TBC

4.2.  SINC over GENEVE Workflow

   TBC

5.  SINC over SFC Considerations

   In this section, SFC, which is a layer 3.5 protocol, is used as a
   running example on how to create a tunnel and encapsulate the SINC
   header, in order to implement the desired in-network computation.

   Figure 2 shows the architecture of a SFC-based SINC network.  In the
   computing service chain, a host sends out packets containing data
   operations to be executed in the network.  The data operation
   description should be carried in the packet itself by using a SINC-
   specific NSH encapsulation added by the Ingres Proxy and trimmed by
   the Egress Proxy.

    +---------+                                          +---------+
    | Host A  |                                          | Host B  |
    +---------+                                          +---------+
         |                     +-----------+                  |
         |                     | SINC SW/R |                  |
    +------------+   +-----+   |  +-----+  |   +-----+   +-----------+
    |SINC Ingress|   |     |   |  |     |  |   |     |   |SINC Egress|
    | Proxy      |-->| SFF |-->|  | SFF |  |-->| SFF |-->| Proxy     |
    +------------+   +-----+   |  +-----+  |   +-----+   +-----------+
                               |     |     |
                               |  +-----+  |
                               |  |  SF |  |
                               |  +-----+  |
                               +-----------+

                   Figure 2: SINC over SFC Architecture.

Lou, et al.               Expires 10 June 2024                  [Page 4]
Internet-Draft       SINC deployment considerations        December 2023

   Once the SINC packet enters into the SFC domain, the Service Function
   Forwarder (SFF) [RFC7665] will forward packets to one or more
   connected service functions according to information carried in the
   SFC encapsulation.  The Service Function (SF) [RFC7665] is
   responsible for implementing data operations.

5.1.  SINC NSH encapsulation

   This section shows how the SINC header can be embedded in the Network
   Service Header (NSH) [RFC8300] for SFC [RFC7665].

   The SINC NSH base header, as shown in Figure 3, is basically another
   type of NSH Meta Data (MD) header.  SINC NSH encapsulation uses the
   NSH MD fixed-length context headers to carry the data operation
   information as show in Figure 3.  Please refer to the NSH [RFC8300]
   for a detailed SFC basic header description.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |ver|O|U|    TTL    |   Length  |U|U|U|U|MD Type| Next Protocol |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 3: NSH Base Header, where 'MD Type' should contain a code-
                          point assigned by IANA.

   Following the NSH basic header there is the Service Path Header, show
   in Figure 4, as defined in [RFC8300].

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Service Path Identifier (SPI)        | Service Index |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 4: NSH Service Path Header.

   The complete SINC NSH header, as shown in Figure 5, stacks the NSH
   base header, NSH Service Path Header, and the SINC Header all
   together.

Lou, et al.               Expires 10 June 2024                  [Page 5]
Internet-Draft       SINC deployment considerations        December 2023

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |ver|O|U|    TTL    |   Length  |U|U|U|U|MD Type| Next Protocol | \N
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S
   |          Service Path Identifier (SPI)        | Service Index | /H
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved  |D|L|                    Group ID                   | \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S
   |     No. of Data Sources       |    Data Source ID             | |I
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N
   |                           SeqNum                              | |C
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   |       Data Operation          |    Data Offset                | /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 5: SINC NSH Header.

5.2.  SINC over SFC Workflow

   For the sake of clarity, a simple example with one sender (Host A)
   and one receiver (Host B) is used to illustrate the workflow.  Packet
   processing goes through the following steps:

   1.  Host A transmits a packet containing a SINC header together with
       data, which will be processed by SFs on SINC capable SW/Rs, to
       the SINC Ingress Proxy.

   2.  The SINC Ingress Proxy encapsulates the original packet with the
       SINC header into a SINC NSH header, as the transport protocol
       indicated by the SFC.

   3.  The SFF forwards the encapsulated packet to the SINC SW/R.

   4.  As shown in Figure 2, when the packet reaches the SINC SW/R, the
       header of the packet will be removed.  The SFF looks up the
       Service Path Identifier (SPI) table and Service Index (SI) table
       and sends the packet to the SF.

   5.  The SF performs the computing based on the defined operation in
       the SINC header after the verification of the Group ID and Data
       Source ID.  The payload will be replaced with the result after
       computation.  The Operation Done flag will be set to 1.  The
       packet is then re-encapsulated with the NSH SINC header.  The SI
       is reduce by 1 while other fields are untouched.  Finally, the
       packet is forwarded to the SINC Egress Proxy.

Lou, et al.               Expires 10 June 2024                  [Page 6]
Internet-Draft       SINC deployment considerations        December 2023

   6.  When the packet reaches the SINC Egress Proxy, it looks up the
       SPI & SI tables and realizes it is the egress.  It removes the
       NSH encapsulation and forwards the inner packet to the final
       destination.

6.  SINC over MPLS Considerations

   In this section, MPLS, which is a layer 2.5 protocol, is used as a
   running example on how to create a tunnel and encapsulate the SINC
   header, in order to implement the desired in-network computation.

   As shown in the Figure 6, the overall architecture is similar to the
   SFC solution.  In this case, the SINC proxy is also a Label Edge
   Router.  The SW/Rs connecting the SINC proxies and SINC SW/Rs are
   Label Switching Routers (LSR).  Before sending out a SINC packet, the
   Label Switched Paths (LSP) should be established between the SINC
   proxies and SINC SW/Rs.  The SINC SW/Rs and proxies can identify a
   SINC packet by the LSPs used.

   Upon receiving a packet with a SINC header, the SINC Ingress Proxy
   encapsulates the packet with a MPLS label(s) according to LSP, before
   forwarding it to the SINC SW/R.  Besides the common LSR functions,
   the SINC SW/R will further identify the location of the SINC header
   by checking the Next Hop Label Forwarding Entry (NHLFE) as defined in
   the [RFC3031].  Usually the next_hop field in the NHLFE will be a
   special loop IP address, which enables the SW/R to send the packet to
   itself, in order to execute the required computation as the header
   defined.  The results will be forwarded to the SINC Egress Proxy
   where the MPLS label will be popped up again before the packet is
   delivered to the destination.

    +---------+                                         +---------+
    | Host A  |                                         | Host B  |
    +---------+                                         +---------+
         |                                                  |
         |                                                  |
    +------------+   +-----+   +-----------+   +-----+   +-----------+
    |SINC Ingress|   |     |   |   SINC    |   |     |   |SINC Egress|
    | Proxy      |-->| LSR |-->|   SW/R    |-->| LSR |-->| Proxy     |
    +------------+   +-----+   +-----------+   +-----+   +-----------+

                   Figure 6: SINC over MPLS Architecture.

6.1.  SINC MPLS encapsulation

   As shown in the Figure 7, one or more MPLS labels are added in front
   of the SINC header.

Lou, et al.               Expires 10 June 2024                  [Page 7]
Internet-Draft       SINC deployment considerations        December 2023

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
   |                  Label                |  TC |S|      TTL      | |M
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P
   ~                 ...                                           ~ |L
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S
   |                  Label                |  TC |S|      TTL      | /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved  |D|L|                    Group ID                   | \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S
   |     No. of Data Sources       |    Data Source ID             | |I
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N
   |                           SeqNum                              | |C
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   |       Data Operation          |    Data Offset                | /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 7: SINC MPLS Header.

6.2.  SINC over MPLS Workflow

   A simple example with one sender (Host A) and one receiver (Host B)
   is used to illustrate the workflow.  Packet processing goes through
   the following steps:

   1.  Host A transmits a packet containing a SINC header together with
       data to the SINC Ingress Proxy.

   2.  Based on the LSP information obtained from control plane, the
       SINC Ingress Proxy builds up a SINC MPLS header pre-pended to the
       original packet.  Then, according to the LSP information, the
       SINC packet is forwarded to the next hop.

   3.  The LSR forwards the packet based on the LSP information obtained
       from control plane.

   4.  As shown in Figure 6, when the packet reaches the SINC node, the
       LSP tunnel ID indicates that this packet contains a SINC header.
       The SINC SW/R pops up the label and hands the packet to in-
       network computing module.  It is worth noting that the
       penultimate hop popping must be disabled.  Otherwise, an
       additional mechanism is needed to signal to the SINC node that
       there is actually a SINC header in the packet.

   5.  The in-network computing module verifies the Group ID and Data
       Source ID in the SINC header, then preforms the required
       computation defined in the Data Operation field.  When it is
       done, the payload is replaced with the result.  The Operation

Lou, et al.               Expires 10 June 2024                  [Page 8]
Internet-Draft       SINC deployment considerations        December 2023

       Done flag will be set to 1.  The SINC SW/R pushes a MPLS label to
       the packet.  Finally, the packet is forwarded to the SINC egress
       proxy.

   6.  When the packet reaches the SINC Egress Proxy, it looks up the
       LSP information and realizes it is the egress.  It pops up the
       MPLS label, replaces the inner SINC header with the outer SINC
       header, and forwards the inner packet to the final destination
       (Host B).

7.  Security Considerations

   In-network computing exposes computing data to network devices, which
   inevitably raises security and privacy considerations.  The security
   problems faced by in-network computing include, but are not limited
   to:

   *  Trustworthiness of participating devices

   *  Data hijacking and tampering

   *  Private data exposure

   This documents assume that the deployment is done in a trusted
   environment.  For example, in a data center network or a private
   network.

   A fine security analysis will be provided in future revisions of this
   memo.

8.  IANA Considerations

   This memo does not contain any request to IANA.

Acknowledgements

   This document received great contribution from Yujing Zhou, as well
   as valuable feedbacks from Dirk Trossen, which was of great help in
   improving the content.  The authors would like to thank all of them.

Normative References

   [I-D.zhou-rtgwg-sinc-00]
              Lou, Z., Iannone, L., Zhou, Y., Yang, J., and Zhangcuimin,
              "Signaling In-Network Computing operations (SINC)", Work
              in Progress, Internet-Draft, draft-zhou-rtgwg-sinc-00, 22
              February 2023, <https://datatracker.ietf.org/doc/html/
              draft-zhou-rtgwg-sinc-00>.

Lou, et al.               Expires 10 June 2024                  [Page 9]
Internet-Draft       SINC deployment considerations        December 2023

   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
              September 1997, <https://www.rfc-editor.org/rfc/rfc2205>.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              DOI 10.17487/RFC2784, March 2000,
              <https://www.rfc-editor.org/rfc/rfc2784>.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <https://www.rfc-editor.org/rfc/rfc3031>.

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
              October 2007, <https://www.rfc-editor.org/rfc/rfc5036>.

   [RFC7498]  Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
              Service Function Chaining", RFC 7498,
              DOI 10.17487/RFC7498, April 2015,
              <https://www.rfc-editor.org/rfc/rfc7498>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/rfc/rfc7665>.

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/rfc/rfc8300>.

   [RFC8926]  Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
              "Geneve: Generic Network Virtualization Encapsulation",
              RFC 8926, DOI 10.17487/RFC8926, November 2020,
              <https://www.rfc-editor.org/rfc/rfc8926>.

Contributors

   Jinze Yang
   China
   Email: jz.yang@live.com

Authors' Addresses

Lou, et al.               Expires 10 June 2024                 [Page 10]
Internet-Draft       SINC deployment considerations        December 2023

   Zhe Lou
   Huawei Technologies
   Riesstrasse 25
   80992 Munich
   Germany
   Email: zhe.lou@huawei.com

   Luigi Iannone
   Huawei Technologies France S.A.S.U.
   18, Quai du Point du Jour
   92100 Boulogne-Billancourt
   France
   Email: luigi.iannone@huawei.com

   Yizhou Li
   Huawei Technologies
   xx
   Nanjing
   xx
   China
   Email: liyizhou@huawei.com

   Cuimin Zhang
   Huawei Technologies
   Huawei base in Bantian, Longgang District
   Shenzhen
   China
   Email: zhangcuimin@huawei.com

Lou, et al.               Expires 10 June 2024                 [Page 11]