Internet DRAFT - draft-zhou-rtgwg-sinc-deployment-considerations
draft-zhou-rtgwg-sinc-deployment-considerations
Network Working Group D. Lou
Internet-Draft L. Iannone
Intended status: Experimental Y. Zhou
Expires: 27 August 2023 J. Yang
C. Zhang
Huawei
23 February 2023
Signaling In-Network Computing operations (SINC) deployment
considerations
draft-zhou-rtgwg-sinc-deployment-considerations-00
Abstract
This document is intended to discuss some aspects of the deployment
of "Signaling In-Network Computing operations" (SINC). Based on the
actual topology of the SINC domain, this document analyzes how each
device in the SINC chain undertakes its own functions. This document
provides some specific solutions to 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 27 August 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Lou, et al. Expires 27 August 2023 [Page 1]
Internet-Draft SINC deployment considerations February 2023
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 . . . . . . . . . . . . . . . 2
4. SINC over SFC Considerations . . . . . . . . . . . . . . . . 4
4.1. SINC NSH encapsulation . . . . . . . . . . . . . . . . . 4
4.2. SINC over SFC Workflow . . . . . . . . . . . . . . . . . 5
5. SINC over MPLS Considerations . . . . . . . . . . . . . . . . 6
5.1. SINC MPLS encapsulation . . . . . . . . . . . . . . . . . 7
5.2. SINC over MPLS Workflow . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Normative References . . . . . . . . . . . . . . . . . . . . . 9
Informative References . . . . . . . . . . . . . . . . . . . . 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 the draft [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
In order to deploy the SINC solution in the network, the packet from
the host needs to be transmitted through a path containing SINC
capable switches/routers (SW/R) for 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
Lou, et al. Expires 27 August 2023 [Page 2]
Internet-Draft SINC deployment considerations February 2023
shown in Figure 1. The packet traveling between Host A and Host B
may pass SINC Node A or 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 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, we could used the MPLS
protocol 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, we may
use the GENEVE protocol 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.
+--------+ +--------+
| 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
Lou, et al. Expires 27 August 2023 [Page 3]
Internet-Draft SINC deployment considerations February 2023
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.
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.
+---------+ +---------+
| Host A | | Host B |
+---------+ +---------+
| +-----------+ |
| | SINC SW/R | |
+------------+ +-----+ | +-----+ | +-----+ +-----------+
|SINC Ingress| | | | | | | | | |SINC Egress|
| Proxy |-->| SFF |-->| | SFF | |-->| SFF |-->| Proxy |
+------------+ +-----+ | +-----+ | +-----+ +-----------+
| | |
| +-----+ |
| | SF | |
| +-----+ |
+-----------+
Figure 2: SINC over SFC Architecture.
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.
Lou, et al. Expires 27 August 2023 [Page 4]
Internet-Draft SINC deployment considerations February 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier (SPI) | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
Lou, et al. Expires 27 August 2023 [Page 5]
Internet-Draft SINC deployment considerations February 2023
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. The SINC SW/R pops up/pushes the
MPLS label before/after the data computation. 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.
Lou, et al. Expires 27 August 2023 [Page 6]
Internet-Draft SINC deployment considerations February 2023
+---------+ +---------+
| 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.
Lou, et al. Expires 27 August 2023 [Page 7]
Internet-Draft SINC deployment considerations February 2023
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 innner 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:
* 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.
Lou, et al. Expires 27 August 2023 [Page 8]
Internet-Draft SINC deployment considerations February 2023
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
Dirk Trossen's feedbacks were of great help in improving this
document.
References
Normative References
[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>.
Lou, et al. Expires 27 August 2023 [Page 9]
Internet-Draft SINC deployment considerations February 2023
[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>.
Informative 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>.
Authors' Addresses
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
Yujing Zhou
Huawei Technologies
Beiqing Road, Haidian District
Beijing
100095
China
Email: zhouyujing3@huawei.com
Lou, et al. Expires 27 August 2023 [Page 10]
Internet-Draft SINC deployment considerations February 2023
Jinze Yang
Huawei Technologies
Beiqing Road, Haidian District
Beijing
100095
China
Email: yangjinze@huawei.com
Cuimin Zhang
Huawei Technologies
Huawei base in Bantian, Longgang District
Shenzhen
China
Email: zhangcuimin@huawei.com
Lou, et al. Expires 27 August 2023 [Page 11]
