Internet-Draft SINC deployment considerations June 2023
Lou, et al. Expires 9 December 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-lou-rtgwg-sinc-deployment-considerations-00
Published:
Intended Status:
Experimental
Expires:
Authors:
D. Lou
Huawei
L. Iannone
Huawei
Y. Li
Huawei
C. Zhang
Huawei

Signaling In-Network Computing operations (SINC) deployment considerations

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 9 December 2023.

▲

Table of Contents

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 assume that the reader is familiar with the Service Function Chaining architecture and Multi-Protocol Label Switching architecture.

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 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 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.

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.

4.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.

 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.

4.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.
  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.

5. 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.

5.1. SINC MPLS encapsulation

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

 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.

5.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 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).

6. 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:

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.

7. 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, , <https://datatracker.ietf.org/doc/html/draft-zhou-rtgwg-sinc-00>.
[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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8926>.

Contributors

Jinze Yang
China

Authors' Addresses

Zhe Lou
Huawei Technologies
Riesstrasse 25
80992 Munich
Germany
Luigi Iannone
Huawei Technologies France S.A.S.U.
18, Quai du Point du Jour
92100 Boulogne-Billancourt
France
Yizhou Li
Huawei Technologies
xx
Nanjing
xx
China
Cuimin Zhang
Huawei Technologies
Huawei base in Bantian, Longgang District
Shenzhen
China