IDR C. Lin Internet Draft New H3C Technologies Intended status: Standards Track H. Yao Expires: December 5, 2024 China Mobile June 6, 2024 Distribute Service Metric By BGP draft-lin-idr-distribute-service-metric-02 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 server 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 December 5, 2024. Copyright Notice Copyright (c) 2024 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 (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 Lin, et al. Expires December 5, 2024 [Page 1] Internet-Draft Distribute Service Metric By BGP June 2024 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 1.3. Overview..................................................5 1.4. Registration and Subscription for Service Metric..........8 2. BGP Service Metric Routes......................................9 2.1. The Service Metric Register NLRI.........................10 2.2. The Service Metric Subscribe NLRI........................11 2.3. The Service Metric Subscribe Option Extended Community...11 2.4. The Service Metric Update NLRI...........................12 2.5. The Service Metric Location Extended Community...........13 2.6. The Service Metric Location IPv6 Extended Community......14 2.7. The Service Metric Priority Extended Community...........15 3. Procedure.....................................................15 4. Security Considerations.......................................18 5. IANA Considerations...........................................18 5.1. Service Metric AFI and SAFI..............................18 5.2. Service Metric Extended Community........................18 6. References....................................................19 6.1. Normative References.....................................19 Authors' Addresses...............................................20 Lin, et al. Expires December 5, 2024 [Page 2] Internet-Draft Distribute Service Metric By BGP June 2024 1. Introduction In scenarios such as edge services and 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 servers, which includes CPU utilization, service queue length, memory usage, and other factors. These operational statuses of the servers 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 server operational status, it is necessary for the server side 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. This document describes a service metric distribution framework based on the BGP protocol, which is designed to support the registration, subscription, 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. Service Metric Routing: Service Metric Routing Ingress Forwarder: Ingress GateWay Egress Forwarder: Egress GateWay Publisher Service Metric Route Publisher Subscriber Service Metric Route Subscriber CATS: Computing-Aware Traffic Steering. Lin, et al. Expires December 5, 2024 [Page 3] Internet-Draft Distribute Service Metric By BGP June 2024 CATS Service ID (CS-ID): An identifier representing a service, which the clients use to access it. [draft-ietf-cats-framework]. CATS Instance Selector ID (CIS-ID): An identifier of a specific service contact instance. [draft-ietf-cats-framework]. RT-EC: Route Target Extended Community [RFC4360]. RD: Route Distinguisher [RFC4364]. 1.2. Gap The process of Service Metric routing involves Egress Forwarder collecting service metric information and notifying it to Ingress Forwarder. When Ingress 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 Forwarder needs to periodically notify the Ingress Forwarder of updates to the service metrics. In the current implementation, BGP utilizes existing IPv4 and IPv6 address families to distribute service metric routes. Consequently, if there are nodes that do not wish to pay attention to Service Metric Routing, additional filtering methods are required to prevent the potential impact on the efficiency of other routes processing. Alternatively, there is a current proposal to use the Service Metric address family to propagate Service Metric routing (Service Metric Routing). The advantage of using a separate Service Metric 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 address family routes. Furthermore, when the Ingress Forwarder router has not yet received service traffic, periodic updates of Service Metric routing are unnecessary. This document presents a registration/subscription mechanism for Service Metric routing, ensuring that subscription 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 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 server. Lin, et al. Expires December 5, 2024 [Page 4] Internet-Draft Distribute Service Metric By BGP June 2024 1.3. 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 servers for the same service, each server 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, we consider adopting a more general approach, which is to use a universal CS-ID instead of IPv4/IPv6 addresses. The mapping from service characteristics to CS-ID is announced by the egress router. The Ingress Forwarder stores the mapping relationship and maps the received service traffic to the corresponding service CS-ID according to the mapping relationship. Service characteristics can include protocol type, service port number, TOS type, and so on. 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 announcing the mapping of service characteristics to CS-ID by the egress router can be abstracted into a module: Publisher. To facilitate the filtering of Service Metric routes by nodes that do not concern Service Metric routing, considering the characteristic of frequent updates in Service Metric routing, this document defines a new BGP address family called Service Metric address family, which leverages the characteristic of frequent updates in Service Metric routing. The Ingress Forwarder receives the service mapping announcement sent by the Publisher and saves the corresponding service mapping. In order to further reduce the bandwidth consumed by Service Metric routes, a subscription mechanism is introduced. If it needs to pay attention to the service metric information, it sends a subscription for service metrics to the Publisher. Here, we abstract a new module called Subscriber. Lin, et al. Expires December 5, 2024 [Page 5] Internet-Draft Distribute Service Metric By BGP June 2024 The Publisher first sends a service registration route to notify the Ingress Forwarder about the existence of Service Metric routes. If the Ingress server needs to subscribe to the service metric information, it acts as a Subscriber and sends a subscription for service metrics to the Publisher. On the contrary, if the Ingress server 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 Publisher receives the service metric subscription sent by the Subscriber, records the subscription status, and sends service metric updates to the Subscriber. In general, the Subscriber only needs to send subscription routes to request service metric information when it receives service requests related to the specific service. However, for simplification purposes, the Subscriber can also choose not to use the subscription mechanism and directly send subscription routes to request service metric information upon receiving registered routes. Sending a subscription 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 server. 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 server. This can also be determined based on the characteristics of each service. For example, for services with higher real-time requirements, immediate subscription can be adopted, while other services can use on-demand subscription. The specific processing steps are as follows: +------------+ +-----------+ |Subscriber | | Publisher | +----+-------+ +-------+---+ |<---1)Type 1: Register Route--------| 2)Service Request--->| | |----3)Type 2: Subscribe Route------>| |<---4)Type 3: Update Route----------| |<---5)Type 3: period Update Route---| Figure 1: BGP Service Metric Route Process 1) The Publisher gathers service information and sends a Register Route to the Subscriber to identify the service characteristics and map the corresponding service to a CS-ID (Service ID). The specific format of registration routes is shown in Section 2.1. If the Subscriber chooses not to use the On-Demand subscription Lin, et al. Expires December 5, 2024 [Page 6] Internet-Draft Distribute Service Metric By BGP June 2024 mechanism, it skips the 2) step and proceeds directly to the 3) step upon receiving registered routes. 2) When the Subscriber receives a service request, it checks if it matches the service characteristics specified in the previously received registered routes. If there is a match, it associates the request with the corresponding service type, as 3). 3) Subscriber sends a Subscribe Route to subscribe the service metric information. The format of the subscription message is shown in Section 2.2. 4) Upon receiving the subscription route, the Publisher sends an Update Route to notify the service metric information. The Update Route format is as shown in Section 2.4. In the case of multiple registrants, the Subscriber needs to send subscription messages to all registrants, and after receiving the Update Route from each Publisher site, it selects the optimal route to guide the Service Metric route forwarding. 5) Thereafter, the Publisher periodically sends Update Routes to update the service metric information when it changes. Lin, et al. Expires December 5, 2024 [Page 7] Internet-Draft Distribute Service Metric By BGP June 2024 1.4. Registration and Subscription for Service Metric ServiceCapTable +--------+ |CS-ID | |Protocol|... |Port | +----+---+ | Register-Table(Type 1 Route) | +--------+ +--------+ +--------+RD1 +----+RD2 |... | +--------+ +--------+ | | Subscrib-Table(Type 2 Route) | +--------+ +--------+ +--------+RD3 +----+RD4 |... | +--------+ +--------+ | | ServiceMetricTable(Type 3 Route) | +-----------+ +-----------+ | |RD1 | |RD2 | | |CIS-ID1 | |CIS-ID2 | +--------+ServerAddr1+----+ServerAddr2|... | |Metric | |Metric | | +-----------+ +-----------+ Figure 2: Registration and Subscription For each service type, maintain a Service Capability Table that records the CS-ID, protocol type, and service port number for each service. When Publisher establishing a new BGP neighbor, the Type 1 register routes is advertised to the neighbor to notify them of the service metric and the associated CS-ID of the service. When Subscriber receives registered routes, it maintains a service information table based on the CS-ID. If local on-demand subscription is required, the Subscriber only sends subscribed routes to the Publisher to request service metric information when it receives a local service request. Otherwise, it directly sends subscribed routes to request service metric information. Upon receiving Type 2 subscribed routes from Scriber, Publisher sends Type 3 updated routes to the subscriber to update the service metric information, and the subscriber of this service is recorded for future use in sending updated routes based on this information. Lin, et al. Expires December 5, 2024 [Page 8] Internet-Draft Distribute Service Metric By BGP June 2024 When the service metric information changes afterwards, Publisher sends Type 3 updated routes to the Subscriber based on the Subscrib- Table. The service metric information is stored as Service Metric Tables and published via Type 3 routes. During publication, it is only sent to subscribers. Subscriber information is stored in the Subscription Table. To avoid frequent updates of service metric information, the updated routes are sent based on the minimum refresh time. 2. 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 Register route + 2 - Service Metric Subscribe route + 3 - Service Metric Update route The detailed encoding and procedures for these route types are described in subsequent sections. The Service Metric NLRI is carried in BGP [RFC4271] using BGP Multiprotocol Extensions [RFC4760] with an AFI of TBD and an SAFI of Service Metric (To be assigned by IANA). The NLRI field in the Lin, et al. Expires December 5, 2024 [Page 9] Internet-Draft Distribute Service Metric By BGP June 2024 MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the Service Metric NLRI (encoded as specified above). 2.1. The Service Metric Register NLRI A Service Metric Register route type specific Service Metric NLRI consists of the following: +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ | CS-ID (Variable) | +---------------------------------------+ | Protocol (2 octets) | +---------------------------------------+ | Service-Port (2 octets) | +---------------------------------------+ The Publisher utilizes Service Metric Register messages to register service characteristics and their associated CS-ID. Subscriber that are interested in this service can subscribe to 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). 2: The CS-ID type is an IPv4 Anycast address (4-byte). 3: The CS-ID type is an IPv6 Anycast address (16-byte). When CS-ID is used as an Anycast address, Protocol and Service-Port are NOT RECOMMENDED. For the purpose of BGP route key processing, only CS-ID is considered to be part of the prefix in the NLRI. The Protocol and Service-Port are to be treated as a route attribute as opposed to being part of the route. Lin, et al. Expires December 5, 2024 [Page 10] Internet-Draft Distribute Service Metric By BGP June 2024 2.2. The Service Metric Subscribe NLRI A Service Metric Subscribe route type specific Service Metric NLRI consists of the following: +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ | CS-ID (Variable) | +---------------------------------------+ There are two instances in which a Subscriber sends a Subscribe message. The first is when on-demand subscription is supported and local service metric information for a requested service is not available. In this scenario, the Subscriber sends a Subscribe message to Publisher based on the registration message in order to request the corresponding service metric information from the Publisher. The second instance is when on-demand subscription is not supported. In this scenario, upon receiving a registration message from the Publisher, the Subscriber immediately sends a Subscribe message to request the corresponding service metric information. Subscribe routing can include Subscribe Option extended community. 2.3. The Service Metric Subscribe Option Extended Community This Extended Community is a new transitive Extended Community having a Type field value of Service Metric (TBD) and the Sub-Type 0x01. It may be advertised along with Service Metric Subscribe routes. Service Metric Subscribe Option extended community 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Sub-Type=0x01 | Subscribe-Option(2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved=0 (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD, 1 octet. Sub-Type: 0x01, 1octet. Lin, et al. Expires December 5, 2024 [Page 11] Internet-Draft Distribute Service Metric By BGP June 2024 Subscribe-Option: 2 octets. 0x01: AggBit, Support for site metric aggregation. 0x02: RawBit, Requesting raw metric information. 2.4. The Service Metric Update NLRI A Service Metric Update route type specific Service Metric NLRI consists of the following: +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ | CS-ID (Variable) | +---------------------------------------+ | CIS-ID (4 octets) | +---------------------------------------+ | Metric (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. The Metric is to be treated as a route attribute as opposed to being part of the route. Metric: includes a 1-byte type field and a variable-length field. Metric Type = 0x01: represents a composite 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x01 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Metric (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Metric (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Average Metric (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Metric Type = 0x02: represents a raw metric information, which is encoded as follows: Lin, et al. Expires December 5, 2024 [Page 12] Internet-Draft Distribute Service Metric By BGP June 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x02 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | total number of Received packets(4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | total number of Send packets(4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | total number of Received bytes(4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | total number of send bytes(4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the Publisher receives a Service Metric subscribe message for the first time, it sends an Update message to the Subscriber 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 subscribers 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. Service Metric Update routing can include Location extended community, Location IPv6 extended community and Priority extended community. 2.5. The Service Metric Location Extended Community This Extended Community is a new transitive Extended Community having a Type field value of Service Metric (TBD) and the Sub-Type 0x02. It may be advertised along with Service Metric Update routes. Service Metric Location extended community 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Sub-Type=0x02 | Reserved=0 | LocationType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Location Value (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD, 1 octet. Sub-Type: 0x02, 1 octet. Lin, et al. Expires December 5, 2024 [Page 13] Internet-Draft Distribute Service Metric By BGP June 2024 Reserved: 1 octet. LocationType: 1 octet, 0x01: IPv4 Server address (4 octets); Location Value: The specific content depends on the LocationType. The IPv4 Server 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 Server address. For example, when the IPv4 Server address is forwarded through SR-MPLS or SRv6, the service routes also inherit the corresponding forwarding path. 2.6. The Service Metric Location IPv6 Extended Community This Extended Community is a new transitive IPv6 Extended Community having a Type field value 0x00 of Service Metric and the Sub-Type (TBD). It may be advertised along with Service Metric Update routes. Service Metric Location IPv6 extended community 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x00 | Sub-Type=TBD | Reserved=0 | LocationType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Location Value (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 0x00, 1 octet. Sub-Type: TBD, 1 octet. Reserved: 1 octet. LocationType: 1 octet, 0x01: IPv6 Server address (16 octets); Location Value: The specific content depends on the LocationType. The IPv6 Server address must be advertised in other address family, such as in the EVPN address family. The routing path for service Lin, et al. Expires December 5, 2024 [Page 14] Internet-Draft Distribute Service Metric By BGP June 2024 routes is forwarded through the actual path corresponding to the IPv6 Server address. For example, when the IPv6 Server address is forwarded through SR-MPLS or SRv6, the service routes also inherit the corresponding forwarding path. 2.7. The Service Metric Priority Extended Community This Extended Community is a new transitive Extended Community having a Type field value of Service Metric (TBD) and the Sub-Type 0x03. It may be advertised along with Service Metric Update routes. Service Metric Priority extended community 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Sub-Type=0x03 | Reserved (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority (2 octets) | Affinity (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD, 1 octet. Sub-Type: 0x03, 1 octet. Priority: 2 octets, Priority of the server. Affinity: 2 octets, Affinity of the gateway where the server is located. 3. Procedure Host------Scriber-----------+--Publisher1 -------Server1 | | (CIS-ID 1, Metric) | +------ Server2 | (CIS-ID 2, Metric) +--Publisher2 -------Server3 | (CIS-ID 3, Metric) +------ Server4 (CIS-ID 4, Metric) Figure 3: Service Metric Network Topology Lin, et al. Expires December 5, 2024 [Page 15] Internet-Draft Distribute Service Metric By BGP June 2024 The host is connected to the Scriber, Server1 and Server2 are connected to Publisher1, while Server3 and Server4 are connected to Publisher2. The following is the process of Scriber and Publisher interacting with BGP for Service Metric routing: 1) Publisher1 sends a Type 1 Registration Route to register the service attributes associated with CS-ID 1. The Scriber receives the registration route and maintains the registration information for this service, recording the association between CS-ID and service attributes. If the Subscriber Forwarder itself does not support on-demand subscription, it directly proceeds to the 3) step and immediately sends Type 2 subscription routes. 2) When the Subscriber Forwarder receives a service request from the Host for the first time, it associates the request with the CS-ID based on the service attributes and the maintained registration information. It then proceeds to the 3): sending Type 2 subscription routes to all the registered Publishers of this service. 3) The Subscriber Forwarder sends a Type 2 subscription route to all registered Publishers of this service based on the CS-ID, in order to request the metric information for this service. 4) When the Publisher1 receives the Type 2 subscription routes, it sends the metric information for this service to subscribers by using Type 3 Update routes. 5) When the Subscriber Forwarder receives Type 3 Update route, Subscriber uses the server address carried by Type 3 Update route to iterate out the outbound interface of the Overlay network to guide the forwarding of Host service messages. 6) Publisher2 establishes a BGP neighborship with Subscriber and sends Type 1 registration routes to register service characteristics, associating them with CS-ID 1. 7) When Subscriber receives new registration routes and if there are already other registrars and service metric tables, it sends subscription routes to the new registrar, requesting new service metric. 8) When there is a change in the service metric, the Publisher1 or Publisher2 sends Type 3 update routes to all subscribers based on the Type 2 subscription routes. Update routes are sent only to the subscribers, which helps in reducing network load. Lin, et al. Expires December 5, 2024 [Page 16] Internet-Draft Distribute Service Metric By BGP June 2024 9) When there is no service traffic for a long period of time, the service metric table is aged out, and Subscriber sends withdrawal of Type 2 subscription routes to all registrars. Publisher advertises the Type 1 Registration Route in the form below: Type 1 Registration Route UPDATE NLRI: AFI=TBD and SAFI=TBD Prefix: RD, CS-ID 1, Protocol, Service-Port NextHop: X.X.X.X (Publisher Address) Attributes: Extended Community RT: (RT-EC) for Server Location VPN Figure 4: Type 1 Registration Route Update Message Subscriber advertises the Type 2 Subscription Route in the form below: Type 2 Subscription Route UPDATE NLRI: AFI=TBD and SAFI=TBD Prefix: RD, CS-ID 1 NextHop: X.X.X.X (Subscriber Address) Attributes: Extended Community RT: (RT-EC) for Host Location VPN Subscribe Option Extended Community: Subscribe-Option=0x01 (for aggregation metric) Figure 5: Type 1 Registration Route Update Message Publisher advertises the Type 3 Update Route in the form below: Type 3 Update Route UPDATE NLRI: AFI=TBD and SAFI=TBD Prefix: RD, CS-ID 1, CIS-ID 1, Metric NextHop: X.X.X.X (Publisher Address) Attributes: Extended Community RT: (RT-EC) for Server Location VPN Location Extended Community: LocationType=0x01 (Server address) Priority Extended Community: Priority=1, Affinity=2 Figure 6: Type 1 Registration Route Update Message Lin, et al. Expires December 5, 2024 [Page 17] Internet-Draft Distribute Service Metric By BGP June 2024 4. Security Considerations TBD. 5. IANA Considerations 5.1. Service Metric AFI and SAFI This document requests a code point for Service Metric AFI and SAFI from the registry of Address Family Numbers and Subsequent Address Family Numbers. This document requests creation of a new registry for Service Metric Register, Service Metric Subscribe, and Service Metric Update. 5.2. Service Metric Extended Community IANA is requested to assign a new extended community attribute type called "Service Metric extended community attribute". Type Description Reference ----- --------------------------------- ------------- TBD Service Metric extended community This document This document request IANA to create the sub-types registry for the "Service Metric extended community Attribute". +==========+===== ===================+===============| | Sub-Type | Name | This document | +==========+=========================+===============| | 0x01 | Subscribe Option | This document | +----------+-------------------------+---------------| | 0x02 | Location | This document | +----------+-------------------------+---------------| | 0x03 | Priority | This document | +----------+-------------------------+---------------| IANA is also requested to assign a new IPv6 extended community attribute sub-type called "Service Metric Location IPv6 extended community attribute". +==========+===== ===================+===============| | Sub-Type | Name | This document | +==========+=========================+===============| | TBD | Location | This document | +----------+-------------------------+---------------| Lin, et al. Expires December 5, 2024 [Page 18] Internet-Draft Distribute Service Metric By BGP June 2024 6. References 6.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 December 5, 2024 [Page 19] Internet-Draft Distribute Service Metric By BGP June 2024 Authors' Addresses Changwang Lin New H3C Technologies 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 December 5, 2024 [Page 20]