]> BGP SR Policy Extensions for Computing-Aware Traffic Steering (CATS) ZTE Corporation
xiong.quan@zte.com.cn
ZTE Corporation
fu.huakai@zte.com.cn
China Mobile
duzongpeng@chinamobile.com
New H3C Technologies
linchangwang.04414@h3c.com
idr An SR (Segment Routing) Policy is a set of candidate paths, each consisting of one or more segment lists. The CATS (Computing-Aware Traffic Steering) can steer traffic between clients of a service and sites offering the service. This document proposes the BGP SR policy extensions for distributing CATS services.
Introduction Segment routing (SR) is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. The ingress node steers packets into a specific path according to the Segment Routing Policy (SR Policy) as defined in . In order to distribute SR policies to the headend, specifies a mechanism by using BGP. The CATS (Computing-Aware Traffic Steering) as per can steer traffic between clients of a service and sites offering the service. Segment Routing (SR) can be used as an encapsulation solution for CATS data plane from an Ingress CATS-Router to an Egress CATS-Router while using an anycast IP address as the Computing-aware Service ID (CS-ID) associated with a service. And the CATS Service Contact Instance ID (CSCI-ID) is representing a specific service contact instance which serves the service request. This document proposes the BGP SR policy extensions for distributing CATS services.
Conventions Used in This Document
Abbreviations
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.
BGP SR Policy for CATS As per , a standalone C-PS can be a functional component of a centralized controller. And C-PS will collect the metric information from C-SMA and C-NMA and also determine the best paths to forward traffic. When the SR is used as the data plane encapsulation for CATS from an Ingress CATS-Router to an Egress CATS-Router, the C-PS or the controller may distribute SR policies to the CATS Ingress CATS-Router. The Figure 1 shows an example of BGP SR Policy for CATS service from CATS-Forwarder 1 as ingress node to CATS-Forwarder 2 as egress node. The SR policy is configured with policy color 100 and NLRI is mapping to the CATS service which is refereed as CS-ID 1. Two service sites with service contact instances represented with CSCI-ID 1 and CSCI-ID 2 are connected to the CATS-Forwarder 2 from the interfaces with Endpoint SID End.DX-1 and End.DX-2. The SR policy may be distributed to carry the identifiers of CATS services.
CATS Service Identifier in SR Policy As per , CS-ID is representing a service in CATS, which the clients use to access it. CSCI-ID is representing a specific service contact instance. As defined in , the SR policy with CS-ID and CSCI-ID encoding structure is shown in Figure 2 as follows: Attributes: Tunnel Encapsulation Attribute (23) Tunnel Type: SR Policy (15) Binding SID SRv6 Binding SID Preference Priority Policy Name Policy Candidate Path Name Explicit NULL Label Policy (ENLP) CS-ID CSCI-ID CSCI-ID ... Segment List Weight Segment Segment ... ... Figure 2: SR policy with CS-ID and CSCI-ID Encoding ]]>
CS-ID Sub-TLV The format of CS-ID Sub-TLV is shown in Figure 3 as follows: where:
  • Type: TBD.
  • Length: variable.
  • Flags: 1 octet of flags. None are defined at this stage. Flags SHOULD be set to zero on transmission and MUST be ignored on receipt.
  • RESERVED: 1 octet of reserved bits. It SHOULD be set to zero on transmission and MUST be ignored on receipt.
  • CS-ID: indicates the identifier associated with the CATS service. It is 4 octets which carry a 32-bit unsigned non-zero number in SR networks and 16 octets which carry a 128-bit unsigned non-zero number in SRv6 networks.
  • sub-TLVs: indicates the CSCI-ID Sub-TLVs that can be carried.
CSCI-ID Sub-TLV The format of CSCI-ID Sub-TLV is shown in Figure 4 as follows: where:
  • Type: TBD.
  • Length: variable.
  • Flags: 1 octet of flags. None are defined at this stage. Flags SHOULD be set to zero on transmission and MUST be ignored on receipt.
  • RESERVED: 1 octet of reserved bits. SHOULD be set to zero on transmission and MUST be ignored on receipt.
  • CSCI-ID: indicates the identifier for a specific service contact instance. It is 4 octets which carry a 32-bit unsigned non-zero number in SR networks and 16 octets which carry a 128-bit unsigned non-zero number in SRv6 networks.
Security Considerations This document defines new BGP Tunnel Encapsulation Attribute sub-TLVs for CATS, which do not introduce any new security considerations beyond those already listed in and .
IANA Considerations IANA is requested to assign a new sub-TLV code point from "BGP Tunnel Encapsulation Attribute sub-TLVs" registry in the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group. This document requests creation of a new registry called "CSCI-ID Sub-TLVs" .
The allocation policy of this registry is "Specification Required" according to . The following initial Sub-TLV codepoints are assigned by this document:
Contributors The following people have substantially contributed to this document:
References Normative References Segment Routing Architecture 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 Policy Architecture Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. Advertising Segment Routing Policies in BGP A Segment Routing (SR) Policy is an ordered list of segments (also referred to as "instructions") that define a source-routed policy. An SR Policy consists of one or more Candidate Paths (CPs), each comprising one or more segment lists. A headend can be provisioned with these CPs using various mechanisms such as Command-Line Interface (CLI), Network Configuration Protocol (NETCONF), Path Computation Element Communication Protocol (PCEP), or BGP. This document specifies how BGP can be used to distribute SR Policy CPs. It introduces a BGP SAFI for advertising a CP of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these CPs. Furthermore, this document updates RFC 9012 by extending the Color Extended Community to support additional steering modes over SR Policy. A Framework for Computing-Aware Traffic Steering (CATS) Huawei Technologies China Mobile Orange Telefonica Independent This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS functional components, describes their interactions, and provides illustrative workflows of the control and data planes. The framework covers only the case of a single service provider. Informative References Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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 over IPv6 (SRv6) Network Programming 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. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226.