]> Huawei

China c.l@huawei.com

China Mobile

China chengweiqiang@chinamobile.com

Huawei

China hongyi.huang@huawei.com

Routing Area SPRING Working Group Service programming Compression In SRv6, an SRv6 SID is a 128-bit value. When too many 128-bit SRv6 SIDs are included in an SRH, the introduced overhead will affect the transmission efficiency of payload. In order to address this problem, Compressed SID(C-SID) is proposed. This document defines new behaviors for service segments with REPLACE-C-SID and NEXT-C-SID flavors to enable compressed SRv6 service programming.

Introduction Segment Routing is a source routing paradigm to support steering packets through a programmed path at the ingress node. Currently, two data planes are defined for Segment Routing: MPLS and IPv6. When IPv6 data plane is used in Segment Routing, it is called SRv6 . defines a new extension header in IPv6, called Segment Routing Header (SRH), to support SRv6. To support SRv6 network programming, defines a framework to build a network program with topological and service segments carried in a Segment Routing header (SRH) . A Service Function Chain (SFC) defines an ordered set of abstract service functions and ordering constraints that must be applied to packets and/or frames and/or flows. A service function chain can be implemented by SRv6 by using a sequence of SRv6 SIDs including service segments defined in . However, when too many 128-bit SRv6 SIDs are included in an SRH, the overhead of the SRH will affect the transmission efficiency of the payload. points out the problem of long SRv6 SID lists reduce payload efficiency. To mitigate such overhead, defines new flavors for basic SR endpoint behaviors defined in . Using the new flavored behavior SID, a 128-bit SRv6 SID can be compressed to be an 32-bit or 16-bit Compressed SID (C-SID), which reduces a lot of size of the SRv6 header. To enable SRv6 SID lists compression for service function chaining (SFC), this document defines new behaviors of service segments with flavors defined in .

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 when, and only when, they appear in all capitals, as shown here.

Terminology This document leverages the terms defined in , , , and . The reader is assumed to be familiar with this terminology. This document does not introduce any new terms.

SR Proxy Behaviors defines several SRv6 endpoint behaviors for service proxy segments. A service proxy segment ID is represented as an 128-bit value just like other SIDs defined in . This section defines some new behaviors of those service proxy segments by combining the existing service proxy segment behaviors with C-SID flavors, such as REPLACE-C-SID flavor and NEXT-C-SID flavor. The main difference between behaviors are the forwarding instructions. Therefore, when C-SID compression mechanism applies to SR Proxy behaviors, the pseudo code of the new behaviors can be generated by updating the forwarding instructions of C-SID to SR proxy forwarding instructions. The following sections define the details of the pseudo code of new behaviors.

Static SR Proxy

Static Proxy for Inner Type Ethernet

REPLACE-C-SID Flavor When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 static proxy SID with the REPLACE-C-SID flavor for Ethernet traffic, the procedure described in is executed except for line S18 and S29 that are both replaced as follows. The upper-layer header processing is unchanged as per . When processing an Ethernet frame received on the interface IFACE-IN and with a destination MAC address that is neither a broadcast address nor matches the address of IFACE-IN, as per .

NEXT-C-SID Flavor When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 static proxy SID with the NEXT-C-SID flavor for Ethernet traffic, the procedure described in is executed except for line S08 of that and line S15 of that are both replaced as follows. The upper-layer header processing is unchanged as per . When processing an Ethernet frame received on the interface IFACE-IN and with a destination MAC address that is neither a broadcast address nor matches the address of IFACE-IN, as per .

Static Proxy for Inner Type IPv4

REPLACE-C-SID Flavor When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 static proxy SID with the REPLACE-C-SID flavor for IPv4 traffic, the procedure described in is executed except for line S18 and S29 that are both replaced as follows. The upper-layer header processing is unchanged as per . When processing an IPv4 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per .

NEXT-C-SID Flavor When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 static proxy SID with the NEXT-C-SID flavor for IPv4 traffic, the procedure described in is executed except for line S08 of that and line S15 of that are both replaced as follows. The upper-layer header processing is unchanged as per . When processing an IPv4 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per .

Static Proxy for Inner Type IPv6

REPLACE-C-SID Flavor When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 static proxy SID with the REPLACE-C-SID flavor for IPv6 traffic, the procedure described in is executed except for line S18 and S29 that are both replaced as follows. The upper-layer header processing is unchanged as per . When processing an IPv6 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per .

NEXT-C-SID Flavor When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 static proxy SID with the NEXT-C-SID flavor for IPv6 traffic, the procedure described in is executed except for line S08 of that and line S15 of that are both replaced as follows. The upper-layer header processing is unchanged as per . When processing an IPv6 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per .

Dynamic SR Proxy

Dynamic Proxy for Inner Type Ethernet

REPLACE-C-SID Flavor When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 dynamic proxy SID with the REPLACE-C-SID flavor for Ethernet traffic, the procedure described in is executed except for line S18 and S29 that are both replaced as follows. The upper-layer header processing is unchanged as per . When processing an Ethernet frame received on the interface IFACE-IN and with a destination MAC address that is neither a broadcast address nor matches the address of IFACE-IN, as per .

NEXT-C-SID Flavor When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 dynamic proxy SID with the NEXT-C-SID flavor for Ethernet traffic, the procedure described in is executed except for line S08 of that and line S15 of that are both replaced as follows. The upper-layer header processing is unchanged as per . When processing an Ethernet frame received on the interface IFACE-IN and with a destination MAC address that is neither a broadcast address nor matches the address of IFACE-IN, as per .

Dynamic Proxy for Inner Type IPv4

REPLACE-C-SID Flavor When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 dynamic proxy SID with the REPLACE-C-SID flavor for IPv4 traffic, the procedure described in is executed except for line S18 and S29 that are both replaced as follows. The upper-layer header processing is unchanged as per . When processing an IPv4 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per .

NEXT-C-SID Flavor When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 dynamic proxy SID with the NEXT-C-SID flavor for IPv4 traffic, the procedure described in is executed except for line S08 of that and line S15 of that are both replaced as follows. The upper-layer header processing is unchanged as per . When processing an IPv4 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per .

Dynamic Proxy for Inner Type IPv6

REPLACE-C-SID Flavor When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 dynamic proxy SID with the REPLACE-C-SID flavor for IPv6 traffic, the procedure described in is executed except for line S18 and S29 that are both replaced as follows. The upper-layer header processing is unchanged as per . When processing an IPv6 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per .

NEXT-C-SID Flavor When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 dynamic proxy SID with the NEXT-C-SID flavor for IPv6 traffic, the procedure described in is executed except for line S08 of that and line S15 of that are both replaced as follows. The upper-layer header processing is unchanged as per . When processing an IPv6 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per .

Shared Memory SR Proxy This document does not define new flavors for shared proxy behavior as it is just an SR endpoint behavior.

Masquerading SR Proxy As per , when forwarding packets to SR-unaware SFs, masquerading SR proxy sets the destination address of the IPv6 header as segment list[0] which is the original final destination address. When receiving the traffic returning from the service, de-masquerading sets the destination address as segment list[Segment Left]. To be consistent with the behavior of masquerading proxy, it's required that any segment list containing one or more masquerading proxy C-SID MUST NOT apply any compression encoding to the last segment (segment list[0]). Note: The service receiving an IPv6 packet from the proxy uses the destination address (copied from last segment) as final destination and could apply certain actions based on that. In order to process and forward packets correctly, it is required that the last segment not be compressed. To be consistent with the behavior of masquerading proxy, when processing an IPv6 packet matching a FIB entry locally instantiated as an SRv6 masquerading C-SID, it's required that the updated destination address MUST be cached in the proxy by adding a dynamic caching mechanism similar to the one described in in case that segment list[Segment Left] is a compressed SID. When processing an IPv6 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, the destination address MUST be recovered from CACHE in case that segment list[Segment Left] could be a C-SID container.

SRv6 Masquerading Proxy Pseudocode

REPLACE-C-SID Flavor When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 masquerading proxy SID with the REPLACE-C-SID flavor, the procedure described in Figure 23 from is executed except for line S18 and S29 that are both replaced as follows. De-masquerading: When processing an IPv6 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, the procedure described in Figure 24 from is executed except for line S10 that is replaced as follows.

NEXT-C-SID Flavor When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 masquerading proxy SID with the NEXT-C-SID flavor, the procedure described in is executed except for line S08 of that and line S15 of that are both replaced as follows. De-masquerading: When processing an IPv6 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, the procedure described in is executed except for line S10 that is replaced as follows.

Destination NAT Flavor

REPLACE-C-SID Flavor The Destination NAT flavor of the SRv6 masquerading proxy with the REPLACE-C-SID is executed except for line S09.1 and S10 in replaced as follows.

NEXT-C-SID Flavor The Destination NAT flavor of the SRv6 masquerading proxy with the NEXT-C-SID is executed except for line S09.1 and S10 in replaced as follows.

Cache Flavor The caching flavor of the SRv6 masquerading proxy with C-SID is enabled as per without any modification.

Security Considerations The security requirements and mechanisms described in and also apply to this document. This document does not introduce any new security considerations.

IANA Considerations TBD

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. China Mobile Cisco Systems Huawei Technologies Orange Cisco Systems This document specifies new flavors for the SR endpoint behaviors defined in RFC 8986, which enable a compressed SRv6 Segment-List encoding in the Segment Routing Header (SRH). Cisco Systems, Inc. China Mobile Cisco Systems, Inc. Bell Canada Huawei Orange Mellanox AT&T Nokia Universita di Roma "Tor Vergata" This document defines data plane functionality required to implement service segments and achieve service programming in SR-enabled MPLS and IPv6 networks, as described in the Segment Routing architecture. Informative References This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols. China Mobile China Telecom Juniper Cisco Systems Huawei ZTE Nokia This document specifies requirements for solutions to compress SRv6 SID lists.

Acknowledgements TBD.