Distribute Service Metric By BGP
draft-lin-idr-distribute-service-metric-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Changwang Lin , Huijuan Yao | ||
| Last updated | 2024-03-04 | ||
| 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-00
IDR C. Lin
Internet Draft New H3C Technologies
Intended status: Standards Track H. Yao
Expires: September 3, 2024 China Mobile
March 4, 2024
Distribute Service Metric By BGP
draft-lin-idr-distribute-service-metric-00
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 September 3, 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
XXX, et al. Expires September 3, 2024 [Page 1]
Internet-Draft Distribute Service Metric By BGP March 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..................................................4
1.4. Registration and Subscription for Service Metric..........7
2. BGP Service Metric Routes .....................................8
2.1. The Service Metric Register NLRI..........................9
2.2. The Service Metric Subscribe NLRI........................10
2.3. The Service Metric Subscribe Option Extended Community...10
2.4. The Service Metric Update NLRI...........................11
2.5. The Service Metric Location Extended Community...........11
2.6. The Service Metric Metric Extended Community.............12
2.7. The Service Metric Raw Metric Extended Community.........13
2.8. The Service Metric Priority Extended Community...........14
3. Example.......................................................14
4. Security Considerations.......................................16
5. IANA Considerations...........................................16
5.1. Service Metric AFI.......................................16
5.2. Service Metric TLV.......................................16
6. References....................................................17
6.1. Normative References.....................................17
Authors' Addresses...............................................18
Lin, et al. Expires September, 2024 [Page 2]
Internet-Draft Distribute Service Metric By BGP March 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
S-ID: Service ID, can be an integer, IPv4, or IPv6 address.
SI-ID: Service Instance ID
Lin, et al. Expires September, 2024 [Page 3]
Internet-Draft Distribute Service Metric By BGP March 2024
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.
1.3. Overview
For Service Metric routers, each service needs to be mapped to a
service ID to differentiate between different services, called S-ID.
The S-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 SI-ID.
When S-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
Lin, et al. Expires September, 2024 [Page 4]
Internet-Draft Distribute Service Metric By BGP March 2024
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 S-ID instead of IPv4/IPv6 addresses.
The mapping from service characteristics to S-ID is announced by the
egress router. The Ingress Forwarder stores the mapping relationship
and maps the received service traffic to the corresponding service
S-ID according to the mapping relationship. Service characteristics
can include protocol type, service port number, TOS type, and so on.
The function of announcing the mapping of service characteristics to
S-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.
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
Lin, et al. Expires September, 2024 [Page 5]
Internet-Draft Distribute Service Metric By BGP March 2024
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 an S-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
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
Lin, et al. Expires September, 2024 [Page 6]
Internet-Draft Distribute Service Metric By BGP March 2024
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.
1.4. Registration and Subscription for Service Metric
ServiceCapTable
+--------+
|S-ID |
|Protocol|...
|Port |
+----+---+
| Register-Table(Type 1 Route)
| +--------+ +--------+
+--------+RD1 +----+RD2 |...
| +--------+ +--------+
|
| Subscrib-Table(Type 2 Route)
| +--------+ +--------+
+--------+RD3 +----+RD4 |...
| +--------+ +--------+
|
| ServiceMetricTable(Type 3 Route)
| +-----------+ +-----------+
| |RD1 | |RD2 |
| |SI-ID1 | |SI-ID2 |
+--------+ServerAddr1+----+ServerAddr2|...
| |Metric | |Metric |
| +-----------+ +-----------+
Figure 2: Registration and Subscription
For each service type, maintain a Service Capability Table that
records the S-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 S-ID of the service.
When Subscriber receives registered routes, it maintains a service
information table based on the S-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
Lin, et al. Expires September, 2024 [Page 7]
Internet-Draft Distribute Service Metric By BGP March 2024
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.
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
Lin, et al. Expires September, 2024 [Page 8]
Internet-Draft Distribute Service Metric By BGP March 2024
+ 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
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) |
+---------------------------------------+
| S-ID (Variable) |
+---------------------------------------+
| Protocol (2 octets) |
+---------------------------------------+
| Service-Port (2 octets) |
+---------------------------------------+
The Publisher utilizes Service Metric Register messages to register
service characteristics and their associated S-ID. Subscriber that
are interested in this service can subscribe to the service metric
information of this service.
S-ID: includes a 1-byte type field and a variable-length field.
Type: 1 Byte, indicates the type of S-ID.
1 the S-ID type is a 4-byte unsigned integer.
2: the S-ID type is a IPv4 address
3: the S-ID type is a IPv6 address
Lin, et al. Expires September, 2024 [Page 9]
Internet-Draft Distribute Service Metric By BGP March 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) |
+---------------------------------------+
| S-ID (Variable) |
+---------------------------------------+
There are two instances in which an 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD, 1 octet.
Sub-Type: 0x01, 1octet.
Subscribe-Option: 2 octets.
Lin, et al. Expires September, 2024 [Page 10]
Internet-Draft Distribute Service Metric By BGP March 2024
* 0x01: AggBit, Support for site routing 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) |
+---------------------------------------+
| S-ID (Variable) |
+---------------------------------------+
| SI-ID (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, metric extended community, Raw metric 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
0x01.
It may be advertised along with Service Metric Update routes.
Service Metric Location extended community is encoded as follows:
Lin, et al. Expires September, 2024 [Page 11]
Internet-Draft Distribute Service Metric By BGP March 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(TBD) | Sub-Type=0x02 | LocationType | ServerAddrType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Location... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ServerAddr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD, 1 octet.
Sub-Type: 0x02, 1octet.
LocationType: 1 octet,
* 0x01: Locationtion is IPv4 address(4 octets);
* 0x02: Location is IPv6 address(16 octets);
* 0x03: mpls label(4 octets);
* 0x04: SRv6 SID(16 octets);
ServerAddrType: 0x01: ServerAddr is IPv4 address(4 octets);
0x02: ServerAddr is IPv6 address(16 octets);
Location: The specific content depends on the LocationType.
ServerAddr: The specific content depends on the ServerAddrType.
2.6. The Service Metric Metric 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 Metric extended community is encoded as follows:
Lin, et al. Expires September, 2024 [Page 12]
Internet-Draft Distribute Service Metric By BGP March 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(TBD) | Sub-Type=0x03 | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxMetric(4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MinMetric(4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AverageMetric(4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD, 1 octet.
Sub-Type: 0x03, 1octet.
MaxMetric: 4 octet, Max Metric
MinMetric: 4 octet, Min Metric
AverageMetric: 4 octet, Average Metric
2.7. The Service Metric Raw Metric Extended Community
This Extended Community is a new transitive Extended Community
having a Type field value of Service Metric (TBD) and the Sub-Type
0x04.
It may be advertised along with Service Metric Update routes.
Service Metric Raw Metric 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=0x04 | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD, 1 octet.
Lin, et al. Expires September, 2024 [Page 13]
Internet-Draft Distribute Service Metric By BGP March 2024
Sub-Type: 0x03, 1octet.
total number of Received packets: 4 octet
total number of Send packets: 4 octet
total number of Received bytes: 4 octets
total number of send bytes: 4 octets
2.8. 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
0x05.
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=0x05 | Priority | Affinity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD, 1 octet.
Sub-Type: 0x05, 1octet.
Priority: 1 octet, Priority of the server
Affinity: 1 octet, Affinity of the server
3. Example
Host------Scriber-----------+--Publisher1 -------Server1
| | (SI-ID 1, Metric)
| +------ Server2
| (SI-ID 2, Metric)
+--Publisher2 -------Server3
| (SI-ID 3, Metric)
+------ Server4
(SI-ID 4, Metric)
Figure 3: Service Metric Network Topology
Lin, et al. Expires September, 2024 [Page 14]
Internet-Draft Distribute Service Metric By BGP March 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 S-ID 1.
The Scriber receives the registration route and maintains the
registration information for this service, recording the association
between S-ID and service attributes.
If the Publisher 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 S-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 subscribers of this
service.
3) The Subscriber Forwarder sends a Type 2 subscription route to all
registered subscribers of this service based on the S-ID, in order
to request the measurement information for this service.
4) When the Publisher1 receives the Type 2 subscription routes, it
sends the measurement information for this service to subscribers
by using Type 3 Update routes.
5) Publisher2 establishes a BGP neighborship with Subscriber and
sends Type 1 registration routes to register service
characteristics, associating them with S-ID 1.
6) 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.
7) 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 September, 2024 [Page 15]
Internet-Draft Distribute Service Metric By BGP March 2024
8) 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.
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.
4. Security Considerations
TBD.
5. IANA Considerations
5.1. Service Metric AFI
This document requests a code point for Service Metric AFI from the
registry of Address Family Numbers.
This document requests creation of a new registry for Service Metric
Register, Service Metric Subscribe, and Service Metric Update.
This document requests a code point from the BGP Path Attributes
registry.
5.2. Service Metric TLV
IANA maintains a registry of "Border Gateway Protocol (BGP)
Parameters" with a subregistry of "BGP Path Attributes".
IANA is requested to assigned a new Path attribute called "Service
Metric attribute".
Value Description Reference
----- --------------- -------------
TBD Service Metric TLV This
document
Figure 3: Service Metric TLV
This document request IANA to created a new subregistry called the
"Service Metric Attribute TLVs" registry
Lin, et al. Expires September, 2024 [Page 16]
Internet-Draft Distribute Service Metric By BGP March 2024
+======+===== ===================+===============|
| Type | Name | This document |
+======+=========================+===============|
| 1 | Subscribe Option TLV | This document |
+------+-------------------------+---------------|
| 2 | Location TLV | This document |
+------+-------------------------+---------------|
| 3 | Metric TLV | This document |
+------+-------------------------+---------------|
| 4 | Raw Metric TLV | This document |
+------+-------------------------+---------------+
| 5 | Priority TLV | This document |
+------+-------------------------+---------------+
6. References
6.1. Normative References
TBD
Lin, et al. Expires September, 2024 [Page 17]
Internet-Draft Distribute Service Metric By BGP March 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 September, 2024 [Page 18]