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, <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 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]