Skip to main content

Distribute Service Metric By BGP
draft-lin-idr-distribute-service-metric-02

Document Type Active Internet-Draft (individual)
Authors Changwang Lin , Huijuan Yao
Last updated 2024-06-05
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-lin-idr-distribute-service-metric-02
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, <https://www.rfc-
                editor.org/info/rfc8174>.
   [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]