IDR C. Lin Internet Draft New H3C Technologies Intended status: Standards Track H. Yao Expires: 13 March 2025 China Mobile November 8, 2024 Distribute Service Metric by BGP draft-lin-idr-distribute-service-metric-04 Abstract When calculating the path selection for service traffic, it is important to consider not only network metrics, but also the impact of service Metric. Therefore, it is necessary to transmit service Metric information from the service site to the user access site, in order to facilitate path selection for service traffic at the access router. This document describes an approach for using the BGP Control Plane to steer traffic based on a set of metrics that reflect the underlying network conditions and other service-specific state collected from available service locations. 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 March 13, 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Lin, et al. Expires March 3, 2025 [Page 1] Internet-Draft Distribute Service Metric By BGP November 2024 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 1.1. Conventions and Terminology...............................3 1.2. Gap.......................................................4 2. Solution.......................................................5 2.1. Overview..................................................5 2.2. Discovery and Notification for Service Metric.............9 3. BGP Service Metric AFI and SAFI...............................10 4. BGP Service Metric Routes.....................................11 4.1. The Service Metric Automatic Discovery NLRI..............12 4.2. The Service Metric Start Notification NLRI...............13 4.3. The Service Metric Update NLRI...........................13 5. Procedure.....................................................17 6. Security Considerations.......................................20 7. IANA Considerations...........................................20 7.1. Service Metric AFI and SAFI..............................20 7.2. Service Metric Route Types Registry......................20 8. References....................................................20 8.1. Normative References.....................................20 Authors' Addresses...............................................21 Lin, et al. Expires March 13, 2025 [Page 2] Internet-Draft Distribute Service Metric By BGP November 2024 1. Introduction In scenarios such as edge services and Computing-Aware Traffic Steering (CATS) services, service instances are deployed across multiple geographically distributed sites to achieve better response times. When selecting a path for service traffic, it is important to consider not only network metrics but also the operational status of the service, which includes CPU utilization, service queue length, memory usage, and other factors. These operational statuses of the service are abstracted as service metrics, allowing service requests to be directed to the optimal service instance based on both network metrics and service metrics. Due to the rapid changes in service operational status, it is necessary for the service site to frequently send update messages regarding its operational status to the user side. Typically, the update frequency ranges from 1 to 5 minutes. In scenarios with a large number of services, frequent updates of service metrics for each service instance can consume a significant amount of network bandwidth. Since BGP has rich routing strategies that can adapt to the diversity and variability of services, and has a route reflector (RR) function that can reduce the session connections for service metric distribution, this document chooses BGP as the control plane of the networks that support service metric distribution. This document describes a service metric distribution framework based on BGP, which is designed to support the automatic discovery, start notification, and updating of service metrics. 1.1. Conventions and Terminology 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the following terms from [draft-ietf-cats- framework]: Computing-Aware Traffic Steering (CATS) CATS Service ID (CS-ID) Lin, et al. Expires March 13, 2025 [Page 3] Internet-Draft Distribute Service Metric By BGP November 2024 CATS Instance Selector ID (CIS-ID) Client Service Ingress CATS-Forwarder Egress CATS-Forwarder Service site Additionally, this document uses the following terms from [RFC4364]: Route Target (RT) Attribute Route Distinguisher (RD) Virtual Private Networks (VPN) This document introduces the following terms: Service Metric Routing: Routing based on Service Metric. Discoverer Egress CATS-Forwarder which connected to the service site. Originator Ingress CATS-Forwarder which connected to the client. 1.2. Gap The process of Service Metric routing involves Egress CATS-Forwarder collecting service metric information and notifying it to Ingress CATS-Forwarder. When Ingress CATS-Forwarder needs to forward service traffic, it selects the optimal path for forwarding based on the network metric and service metric information. Due to the frequent changes in service metrics, the Egress CATS- Forwarder needs to periodically notify the Ingress CATS-Forwarder of updates to the service metrics. In the current implementation, BGP uses existing address families to distribute service metric routes. Consequently, if there are nodes that do not need to consider Service Metric Routing, additional filtering methods are required to avoid potential impacts on the efficiency of other route processing. Additionally, the CS-ID identifying the service does not necessarily have to be an anycast address. The existing address families are not sufficient to support Lin, et al. Expires March 13, 2025 [Page 4] Internet-Draft Distribute Service Metric By BGP November 2024 future flexible expansion. Moreover, injecting periodically changing metric attributes into the existing address families may affect their stability. It is also essential to prevent attribute leaks to avoid security risks. Alternatively, there is a current proposal to use a new BGP address family to propagate Service Metric Routing. The advantage of using a separate BGP address family is that routers not involved in service traffic processing are unaffected by Service Metric routing, as they do not pay attention to Service Metric routes. And the new BGP address family is highly extensible and can flexibly design packet formats, making packet packaging more efficient and reducing network load. Furthermore, when the Ingress CATS-Forwarder router has not yet received service traffic, periodic updates of Service Metric routing are unnecessary. This document presents a filtering notification mechanism for Service Metric routing, ensuring that notification to the corresponding Service Metric routing is only required when handling the respective service traffic. In this scenario, for environments supporting multiple services simultaneously, the Ingress CATS-Forwarder router only needs to focus on the Service Metric routing related to the services it handles. This approach significantly reduces the burden on the Ingress CATS-Forwarder. 2. Solution To minimize the impact on existing routing information and to enhance security and scalability, service metrics are transmitted via an independent new address family. 2.1. Overview For Service Metric routers, each service needs to be mapped to a service ID to differentiate between different services, called CS- ID. The CS-ID can be an IPv4 address, an IPv6 address, or more abstractly, an integer. To differentiate between different service sites for the same service, each service site is assigned a service instance ID, called CIS-ID. When CS-ID is used as an IPv4 or IPv6 address, it corresponds to the Anycast mode. The advantage of using Anycast mode is that it can leverage the existing routing and forwarding infrastructure. However, the drawback is that it can impact non-Service Metric routing, as all routers have to process Anycast routes. Therefore, Lin, et al. Expires March 13, 2025 [Page 5] Internet-Draft Distribute Service Metric By BGP November 2024 we consider adopting a more general approach, which is to use a universal CS-ID instead of IPv4/IPv6 addresses. The processing flow of this new approach is shown in the figure 1. The reachability information of the service site location is published to the ingress device through the BGP existing address family or other routing protocols to ensure the reachability of the service site location. The egress device sends the service metric information to the ingress device through the BGP new address family. The service metric information carries the service location information, and the outbound interface information of service is iterated through the service location information to form the service forwarding information, which is used to guide the forwarding of service traffic. +---------+ +--------+ Client--| Ingress |------------------------| Egress |--Service site +---------+ +--------+ ++++++++++++|+++++++++++++++++++++++++++++++++++|+++++++++++++++++++ |<----------service metric----------| Control | | |<--service location reachability---| ++++++++++++|+++++++++++++++++++++++++++++++++++|+++++++++++++++++++ | | Forwarding |--service forwarding information-->| | | Figure 1: New approach Processing Flow The mapping from service characteristics to CS-ID needs to be announced by the egress router. The Ingress CATS-Forwarder stores the mapping relationship and maps the received service traffic to the corresponding service CS-ID according to the mapping relationship. Service characteristics could include protocol type, service port number, TOS type, and so on. How the service characteristics is defined, and how the mapping relationship is published, are out of the scope of this document. When CS-ID is used as an Anycast address, no service characteristics are required since the destination address of the service request message is the Anycast address of CS-ID. The function of automatically discovering and announcing the mapping of service characteristics to CS-ID by the egress router can be abstracted into a module: Discoverer. To facilitate the filtering of Service Metric routes by nodes that do not concern Service Metric routing, considering the Lin, et al. Expires March 13, 2025 [Page 6] Internet-Draft Distribute Service Metric By BGP November 2024 characteristic of frequent updates in Service Metric routing, this document defines a new BGP Address-Family called BGP Service Metric (SM) AFI, and two new BGP Sub-Address-Family (BGP SM SAFI and BGP VPN SM SAFI), which leverages the characteristic of frequent updates in Service Metric routing. The Ingress CATS-Forwarder receives the service mapping announcement sent by the Discoverer and saves the corresponding service mapping. In order to further reduce the bandwidth consumed by Service Metric routes, a dynamic filtering notification mechanism is introduced. If it needs to pay attention to the service metric information, it sends a Start-Notification for service metrics to the Discoverer. Here, we abstract a new module called Originator. The Discoverer first sends a service automatic discovery route to notify the Ingress CATS-Forwarder about the existence of Service Metric routes. If the Ingress CATS-Forwarder needs to obtain the service metric information, it acts as an Originator and sends a start notification for service metrics to the Discoverer. On the contrary, if the Ingress CATS-Forwarder hasn't received any traffic related to the service yet, it doesn't need to pay attention to the service metrics at the moment. Subsequently, The Discoverer receives the service metric start notification message sent by the Originator, records the start notification status, and sends service metric updates to the Originator. In general, the Originator only needs to send start notification routes to request service metric information when it receives service requests related to the specific service. However, for simplification purposes, the Originator can also choose not to use the dynamic filtering notification mechanism and directly send start notification routes to request service metric information upon receiving automatic discovery routes. Sending a start notification message without any service traffic can improve the response speed when the service traffic is first received. However, the downside is that it increases the load on the Ingress CATS-Forwarder. The specific usage scenario needs to be assessed based on whether priority is given to the response speed to service requests or to reducing the load on the Ingress CATS- Forwarder. This can also be determined based on the characteristics of each service. For example, for services with higher real-time requirements, immediate notification can be adopted, while other services can use on-demand notification. The specific processing steps are as follows: Lin, et al. Expires March 13, 2025 [Page 7] Internet-Draft Distribute Service Metric By BGP November 2024 +------------+ +------------+ | Originator | | Discoverer | +-----+------+ +--------+---+ |<--1)Type 1: Auto-Discovery Route-------| 2)Service Request-->| | |---3)Type 2: Start-Notification Route-->| |<--4)Type 3: Update Route---------------| |<--5)Type 3: period Update Route--------| Figure 2: BGP Service Metric Route Process 1) The Discoverer gathers service information and sends an Automatic Discovery Route to the Originator to indicate the existence of a service. The specific format of Automatic Discovery routes is shown in Section 3.1. If the Originator chooses not to use the On- Demand filtering notification mechanism, it skips the 2) step and proceeds directly to the 3) step upon receiving Automatic Discovery routes. 2) When the Originator receives a service request, it checks if it matches the characteristics of service specified in the previously received Automatic Discovery routes. If there is a match, it associates the request with the corresponding service type, as 3). 3) Originator sends a Start Notification Route to obtain the service metric information. The format of the Start Notification message is shown in Section 3.2. 4) Upon receiving the Start Notification route, the Discoverer sends an Update Route to notify the service metric information. The Update Route format is as shown in Section 3.4. In the case of multiple discoverers, the Originator needs to send Start Notification messages to all discoverers, and after receiving the Update Route from each Discoverer site, it selects the optimal route to guide the Service Metric route forwarding. 5) Thereafter, the Discoverer periodically sends Update Routes to update the service metric information when it changes. Lin, et al. Expires March 13, 2025 [Page 8] Internet-Draft Distribute Service Metric By BGP November 2024 2.2. Discovery and Notification for Service Metric +---------------------------------------------+ | Discovery-Table (Type 1 Route) | | +--------+ +--------+ | |--------|CS-ID | |CS-ID |... | | +--------+ +--------+ | | | | Notification-Table (Type 2 Route) | | +--------+ +--------+ | |--------|CS-ID | |CS-ID |... | | +--------+ +--------+ | | | | Metric-Table (Type 3 Route) | | +-----------+ +-----------+ | | |CS-ID | |CS-ID | | | |CIS-ID1 | |CIS-ID2 | | +--------+Location1 +----+Location2 |... | | |Metric1 | |Metric2 | | | +-----------+ +-----------+ | +---------------------------------------------+ Figure 3: Service Metric Table for Public Network +---------------------------------------------+ | Discovery-Table (Type 1 Route) | | +--------+ +--------+ | +--------+RD1 +----+RD2 | | | |CS-ID | |CS-ID |... | | +--------+ +--------+ | | | | Notification-Table (Type 2 Route) | | +--------+ +--------+ | +--------+RD3 +----+RD4 | | | |CS-ID | |CS-ID |... | | +--------+ +--------+ | | | | Metric-Table (Type 3 Route) | | +-----------+ +-----------+ | | |RD1 | |RD2 | | | |CS-ID | |CS-ID | | | |CIS-ID1 | |CIS-ID2 | | +--------+Location1 +----+Location2 |... | | |Metric1 | |Metric2 | | | +-----------+ +-----------+ | +---------------------------------------------+ Figure 4: Service Metric Table for VPN Network Lin, et al. Expires March 13, 2025 [Page 9] Internet-Draft Distribute Service Metric By BGP November 2024 For each service type, maintain a Service Metric Table that records the CS-ID for each service. As shown in Figures 3 and 4, The Service Metric Table consists of a Discovery Table, a Notification Table, and a Metric Table. For VPN network, the service table contains RD, while for public network, it does not contain RD. When Discoverer establishing a new BGP neighbor, the Type 1 automatic discovery routes is advertised to the neighbor to notify the associated CS-ID of the service. When Originator receives discovery routes, it maintains a service discovery table based on the CS-ID. If local on-demand filtering notification is required, the Originator only sends start notification routes to the Discoverer to request service metric information when it receives a local service request. Otherwise, it directly sends start notification routes to request service metric information. Upon receiving Type 2 start notification routes from Originator, Discoverer sends Type 3 updated routes to the Originator to update the service metric information, and the Originator of this service is recorded for future use in sending updated routes based on this information. When the service metric information changes afterwards, Discoverer sends Type 3 updated routes to the Originator based on the Notification-Table. The service metric information is stored as Service Metric Tables and published via Type 3 routes. During publication, it is only sent to originators. Start Notification information is stored in the Notification Table. To avoid frequent updates of service metric information, the updated routes are sent based on the minimum refresh time. 3. BGP Service Metric AFI and SAFI In order to carry out the transmission of service metric information between different routers, this document defines a new BGP Service Metric Address Family Identifier (BGP SM AFI) and two new BGP Service Metric Subsequent Address Family Identifier (BGP SM SAFI and BGP VPN SM SAFI). Both SM SAFI and VPN SM SAFI SHOULD be applied to BGP SM AFI. BGP SM SAFI can be enabled on transport devices in a provider network (underlay) to complete service metric transport across the Lin, et al. Expires March 13, 2025 [Page 10] Internet-Draft Distribute Service Metric By BGP November 2024 provider network. The multi-domain transport network may comprise of multiple BGP ASs as well as multiple IGP domains within a single BGP AS. BGP SM SAFI can also be enabled within a VRF on a PE router towards a peering CE router, and on devices within a customer network. BGP VPN SM SAFI is used for the distribution of service metric routes from different customers received on a PE router across the provider network, maintaining the separation of the customer address spaces that may overlap. This document also defines an extensible NLRI model for both SAFIs that allow multiple NLRI types to be defined for different use cases. Each type of NLRI contains key and TLV based non-key fields for efficient encoding of different per-prefix information. The specific format information of the NLRI will be described in section 3. 4. BGP Service Metric Routes This document defines a new BGP Network Layer Reachability Information (NLRI) called the Service Metric NLRI. The format of the Service Metric NLRI is as follows: +-----------------------------------+ | Route Type (1 octet) | +-----------------------------------+ | Length (1 octet) | +-----------------------------------+ | Route Type specific (variable) | +-----------------------------------+ The Route Type field defines the encoding of the rest of the Service Metric NLRI (Route Type specific Service Metric NLRI). The Length field indicates the length in octets of the Route Type specific field of the Service Metric NLRI. This document defines the following Route Types: + 1 - Service Metric Automatic Discovery route + 2 - Service Metric Start Notification route + 3 - Service Metric Update route The detailed encoding and procedures for these route types are described in subsequent sections. Lin, et al. Expires March 13, 2025 [Page 11] Internet-Draft Distribute Service Metric By BGP November 2024 The Service Metric NLRI is carried in BGP [RFC4271] using BGP Multiprotocol Extensions [RFC4760] with an AFI of TBD and two SAFIs of Service Metric (To be assigned by IANA). The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the Service Metric NLRI (encoded as specified above). Because the Service Metric Route does not use the next hop address of the MP_REACH_NLRI attribute, the length of Next Hop Network Address is set to 0, which helps to package service metric routes, that is, encapsulate multiple NLRIs in the same BGP update message to reduce network overhead. 4.1. The Service Metric Automatic Discovery NLRI For BGP SM SAFI, A Service Metric Automatic Discovery route type specific Service Metric NLRI consists of the following: +---------------------------------------+ | CS-ID (Variable) | +---------------------------------------+ For BGP VPN SM SAFI, A Service Metric Automatic Discovery route type specific Service Metric NLRI consists of the following: +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ | CS-ID (Variable) | +---------------------------------------+ The Discoverer utilizes Service Metric Automatic Discovery messages to publish service characteristics and their associated CS-ID. Originator that are interested in this service can need to obtain the service metric information of this service. CS-ID: includes a 1-byte type field and a variable-length field. Type: 1 Byte, indicates the type of CS-ID. 1 The CS-ID type is a 4-byte unsigned integer, and also contains 1-byte address family identifier (AFI = IPv4 or IPv6). AFI indicates the address family to which the service belongs. 2: The CS-ID type is an IPv4 Anycast address (4-byte), which indicates that the service belongs to the IPv4 Lin, et al. Expires March 13, 2025 [Page 12] Internet-Draft Distribute Service Metric By BGP November 2024 address family. 3: The CS-ID type is an IPv6 Anycast address (16-byte), which indicates that the service belongs to the IPv6 address family. For the purpose of BGP route key processing, only CS-ID is considered to be part of the prefix in the NLRI. 4.2. The Service Metric Start Notification NLRI For BGP SM SAFI, A Service Metric Start Notification route type specific Service Metric NLRI consists of the following: +---------------------------------------+ | CS-ID (Variable) | +---------------------------------------+ For BGP VPN SM SAFI, A Service Metric Start Notification route type specific Service Metric NLRI consists of the following: +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ | CS-ID (Variable) | +---------------------------------------+ There are two instances in which a Discoverer sends an Automatic Discovery message. The first is when on-demand filtering notification is supported and local service metric information for a requested service is not available. In this scenario, the Originator sends a Start Notification message to Discoverer based on the automatic discovery message in order to request the corresponding service metric information from the Discoverer. The second instance is when on-demand filtering notification is not supported. In this scenario, upon receiving an automatic discovery message from the Discoverer, the Originator immediately sends a Start Notification message to request the corresponding service metric information. 4.3. The Service Metric Update NLRI For BGP SM SAFI, A Service Metric Update route type specific Service Metric NLRI consists of the following: Lin, et al. Expires March 13, 2025 [Page 13] Internet-Draft Distribute Service Metric By BGP November 2024 +---------------------------------------+ | CS-ID (Variable) | +---------------------------------------+ | CIS-ID (4 octets) | +---------------------------------------+ | Non-Key Field (Variable) | +---------------------------------------+ For BGP VPN SM SAFI, A Service Metric Update route type specific Service Metric NLRI consists of the following: +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ | CS-ID (Variable) | +---------------------------------------+ | CIS-ID (4 octets) | +---------------------------------------+ | Non-Key Field (Variable) | +---------------------------------------+ For the purpose of BGP route key processing, only CS-ID and CIS-ID are considered to be part of the prefix in the NLRI. CIS-ID can be an address or an integer. To simplify the implementation, this article defines CIS-ID as a 4-byte integer. The Non-Key Field is to be treated as a route attribute as opposed to being part of the route. The Non-Key Field is a series of TLV format contents. Non-Key (NK) Field: includes a 1-byte type field, a 1-byte length field and a variable-length value field. Non-Key (NK) Type = 0x01: represents metric information, which is encoded as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NK Type=0x01 |Length(1 octet)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric (Variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, * Metric field: is defined here to be a set of elements encoded as "M-Type/Length/Flag/Value" (i.e., a set of TLVs). Each such TLV is encoded as shown blow: Lin, et al. Expires March 13, 2025 [Page 14] Internet-Draft Distribute Service Metric By BGP November 2024 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M-Type(1 octet)|Length(1 octet)| Flag(1 octet) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (Variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, Flag must be set to 0 if it is not used, and M-Type defines three commonly used types, as follows: * M-Type = 0x01: represents a composite metric information, which is usually used to represent the execution capability of the service when a service has no special application requirements. The composite metric is an average of the raw metrics of the service, but the specific calculation method is beyond the scope of this article. This composite metric type is encoded as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M-Type=0x01 |Length(1 octet)| Flag(1 octet) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Composite Metric Value (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, The Flag carry additional information about the composite metric, the Flag is encoded as follows: 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ | Resv |R| +-+-+-+-+-+-+-+-+ Bit R: represents composite metrics belonging to resource types. 1 indicates resource type, 0 indicates non-resource type. Resv: Reserved for future use. MUST be set to zero. * M-Type = 0x02: represents a latency metric information, which is usually used as an indicator for selecting services when such services are sensitive to low latency. Calculation of latency in the network is beyond the scope of this document. This latency metric type is encoded as follows: Lin, et al. Expires March 13, 2025 [Page 15] Internet-Draft Distribute Service Metric By BGP November 2024 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M-Type=0x02 |Length(1 octet)| Flag(1 octet) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Latency Value (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * M-Type = 0x03: represents a weight metric information, which is used as the weight value for selecting a service when the service needs to support load balancing deployment network. Again, the calculation of the weight is beyond the scope of this document. This weight metric type is encoded as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M-Type=0x03 |Length(1 octet)| Flag(1 octet) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Weight Value (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Non-Key Type = 0x02: represents a Location information of service site, which is encoded as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NK Type=0x02 |Length(1 octet)| Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Location Value (Variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, Sub-Type: 1 octet, 0x01: Location Value is IPv4 address (4 octets); 0x02: Location Value is IPv6 address (16 octets); Location Value: The Location address of service site, the specific content depends on the Sub-Type. The IPv4 or IPv6 Service site address must be advertised in other address family, such as in the EVPN address family. The routing path for service routes is forwarded through the actual path corresponding to the IPv4 or IPv6 Service site address. For example, when the IPv4 or IPv6 Service site address is forwarded through SR- Lin, et al. Expires March 13, 2025 [Page 16] Internet-Draft Distribute Service Metric By BGP November 2024 MPLS or SRv6, the service routes also inherit the corresponding forwarding path. Non-Key Type = 0x03: represents a Priority information, which is encoded as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NK Type=0x03 |Length(1 octet)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority (2 octets) | Affinity (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, Priority: 2 octets, Priority of the Service site. Affinity: 2 octets, Affinity of the gateway where the Service site is located. When the Discoverer receives a Service Metric start notification message for the first time, it sends an Update message to the Originator to notify the update of service metric information. Subsequently, if there are any changes in the service metric information, an Update message is sent to the originators to notify the update of service metric information. To avoid frequent updates of service metric, it is necessary to have a last update period to control the minimum interval for updating the service metric of a specified service. 5. Procedure +----------+ +----+ +-----------+ Client--+Originator+---+ RR +---+Discoverer1+----Service site 1 +----------+ +--+-+ +-----+-----+ (CIS-ID 1, Metric) | | | +----------Service site 2 | (CIS-ID 2, Metric) | +-----------+ +-----+Discoverer2+----Service site 3 +-----+-----+ (CIS-ID 3, Metric) | +----------Service site 4 (CIS-ID 4, Metric) Figure 5: Service Metric Network Topology Lin, et al. Expires March 13, 2025 [Page 17] Internet-Draft Distribute Service Metric By BGP November 2024 The client is connected to the Originator, Service site 1 and Service site 2 are connected to Discoverer1, while Service site 3 and Service site 4 are connected to Discoverer2. The route reflector (RR) is used to receive and advertise service metric routes from all CATS-Forwarders which include Originator and Discoverer. The following is the process of Originator and Discoverer interacting with BGP for Service Metric routing: 1) Discoverer1 sends a Type 1 Automatic Discovery Route to announce the service attributes associated with CS-ID 1. The Originator receives the Automatic Discovery route and maintains the discovery information for this service, recording the association between CS-ID and service attributes. If the Originator Forwarder itself does not support on-demand filtering notification, it directly proceeds to the 3) step and immediately sends Type 2 start notification routes. 2) When the Originator Forwarder receives a service request from the Client for the first time, it associates the request with the CS- ID based on the service attributes and the maintained discovery information. It then proceeds to the 3): sending Type 2 start notification routes to all the recorded Discoverers of this service. 3) The Originator Forwarder sends a Type 2 start notification route to all recorded Discoverers of this service based on the CS-ID, in order to request the metric information for this service. 4) When the Discoverer1 receives the Type 2 start notification routes, it sends the metric information for this service to originators by using Type 3 Update routes. 5) When the Originator Forwarder receives Type 3 Update route, Originator uses the Service site address carried by Type 3 Update route to iterate out the outbound interface of the Overlay network to guide the forwarding of Client service messages. 6) Discoverer2 establishes a BGP neighbor ship with Originator and sends Type 1 automatic discovery routes to notice service characteristics, associating them with CS-ID 1. 7) When Originator receives new discovery routes and if there are already other discoverers and service metric tables, it sends start notification routes to the new discoverer, requesting new service metric. Lin, et al. Expires March 13, 2025 [Page 18] Internet-Draft Distribute Service Metric By BGP November 2024 8) When there is a change in the service metric, the Discoverer1 or Discoverer2 sends Type 3 update routes to all originators based on the Type 2 start notification routes. Update routes are sent only to the originators, which helps in reducing network load. 9) When there is no service traffic for a long period of time, the service metric table is aged out, and Originator sends withdrawal of Type 2 start notification routes to all discoverers. Discoverer advertises the Type 1 Automatic Discovery Route for BGP VPN SM SAFI in the form below: Type 1 Automatic Discovery Route UPDATE NLRI: AFI=TBD and SAFI=TBD Prefix: RD, CS-ID 1 Next Hop Length: 0 Attributes: Extended Community RT: RT Attribute for Service site Location VPN Figure 6: Type 1 Automatic Discovery Route Update Message Originator advertises the Type 2 Start Notification Route for BGP VPN SM SAFI in the form below: Type 2 Start Notification Route UPDATE NLRI: AFI=TBD and SAFI=TBD Prefix: RD, CS-ID 1 Next Hop Length: 0 Attributes: Extended Community RT:RT Attribute for Client Location VPN Figure 7: Type 2 Start Notification Route Update Message Discoverer advertises the Type 3 Update Route for BGP VPN SM SAFI in the form below: Type 3 Update Route UPDATE NLRI: AFI=TBD and SAFI=TBD Prefix: RD, CS-ID 1, CIS-ID 1 Non-Key Field: Metric (Composite Metric), Location (IPv4 Service site address), Priority (Priority=1, Affinity=2) Next Hop Length: 0 Attributes: Lin, et al. Expires March 13, 2025 [Page 19] Internet-Draft Distribute Service Metric By BGP November 2024 Extended Community RT: RT Attribute for Service site Location VPN Figure 8: Type 3 Update Route Update Message 6. Security Considerations TBD. 7. IANA Considerations 7.1. Service Metric AFI and SAFI This document requests a code point for Service Metric AFI (SM AFI) and SAFIs (SM SAFI and VPN SM SAFI) from the registry of Address Family Numbers and Subsequent Address Family Numbers. 7.2. Service Metric Route Types Registry This document requests creation of a new registry for Service Metric Automatic Discovery, Service Metric Start Notification, and Service Metric Update. And IANA is requested to assign a new registry for "Non-Key Field" of Service Metric Update NLRI. Also IANA is requested to assign a new registry for Metric type of Metric information in Service Metric Update NLRI. 8. Acknowledgements The authors would like to thank Susan Hares for their comments to this document. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D. draft-ietf-cats-framework-02] C. Li.,Z. Du.,M. Boucadair., L. M. Contreras.,J. Drake., " A Framework for Computing-Aware Traffic Steering (CATS)", draft-ietf-cats-framework-02(work in progress), April 2024. Lin, et al. Expires March 13, 2025 [Page 20] Internet-Draft Distribute Service Metric By BGP November 2024 Authors' Addresses Changwang Lin New H3C Technologies Beijing China Email: linchangwang.04414@h3c.com Huijuan Yao China Mobile No.32 XuanWuMen West Street Beijing 100053 China Email: yaohuijuan@chinamobile.com Lin, et al. Expires March 13, 2025 [Page 21]