| Internet-Draft | Abbreviated-Title | March 2023 |
| Zhang, et al. | Expires 14 September 2023 | [Page] |
SR Policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. DetNet provides the capability to carry specified unicast or multicast data flows with extremely low data loss rates and bounded end-to-end latency within a network domain. This document defines the SR policy enhancement to carry the Bounded Latency Information with a candidate path of SR policy. So that BLI behavior can be enabled automatically when the SR Policy is applied.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
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 14 September 2023.¶
Copyright (c) 2023 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Segment Routing Policy is defined in[I-D.ietf-spring-segment-routing-policy]. A SR Policy is a set of candidate path which consist of one or more segment lists. The headend node instructs the source routing and writes it into package. The packets steered into an SR Policy have an ordered list of segments associated with that SR Policy written into them.[RFC8655] provides the overall architecture for Deterministic Networking (DetNet), which provides the capability to carry specified unicast or multicast data flows with extremely low data loss rates and bounded end-to-end latency within a network domain. Based on this,[I-D.ietf-detnet-bounded-latency] proposed a timing model for sources, destinations, and DetNet transit nodes. Using the model, it provides a methodology to compute end-to-end latency and backlog bounds for various queuing methods.[I-D.yzz-detnet-enhanced-data-plane] enhances the DetNet data plane by introducing Bounded Latency Information (BLI) which facilitates DetNet transit nodes to guarantee the bounded latency transmission in data plane. Based on that,[I-D.geng-spring-sr-enhanced-detnet] defines how to leverage Segment Routing (SR) and Segment Routing over IPv6 (SRv6) to implement bounded latency. For An automatic network, the SR Policy with Bounded Latency Information can facilitate the bounded latency transmission and enable the automation of SR service.¶
This document defines the SR policy enhancement to carry the Bounded Latency Information with a candidate path of SR policy. So that BLI behavior can be enabled automatically when the SR Policy is applied.¶
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[RFC2119].¶
The abbreviations used in this document are:¶
BLI: Bounded Latency Information¶
SR: Segment Routing¶
SID: Segment Identifier¶
The BLI is proposed by[I-D.yzz-detnet-enhanced-data-plane] to facilitate DetNet transit nodes to guarantee the bounded latency transmission in data plane. In order to specify the bounded latency features that the candidate path is associated with, this document defines two types of new sub-TLV in the BGP Tunnel Encapsulation Attribute for SR Policy[I-D.ietf-spring-segment-routing-policy] for different scenarios.¶
When all of the nodes/adjacencies in the explicit path indicated by the segment list request different BLI to guarantee bounded latency, a BLI list sub-TLV is defined.¶
The BLI list sub-TLV is formatted 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BLI List [m] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BLI List [1] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
Type: to be assigned by IANA.¶
Length: 16 bits length value to indicate the length of BLI list in octet.¶
BLI List [1… m]: 64 bits length BLI structure, representing the nth BLI in the BLI list.¶
The BLI in the BLI List corresponds to the Segment in the Segment List one by one. The length of the BLI List depends on the num of Segment in the Segment List.¶
The encoding structure of BGP SR Policy with the BLI list sub-TLV is expressed as below:¶
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes:
Tunnel Encaps Attribute (23)
Tunnel Type: SR Policy
Binding SID
Preference
Priority
Policy Name
Explicit NULL Label Policy (ENLP)
Segment List
BLI List
Weight
Segment
Segment
...
...
¶
When all of the nodes/adjacencies in the explicit path indicated by the segment list request BLI to guarantee bounded latency with the same BLI value, the Shared BLI sub-TLV is defined.¶
The Shared BLI sub-TLV is defined 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 (TBD2) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BLI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
Type: to be assigned by IANA.¶
Length: 16 bits value indicate the length of BLI.¶
BLI: 64 bits value of Bounded Latency Information to guarantee the bounded latency, the format of it is defined in section 3.1.¶
The encoding structure of BGP SR Policy with the Per-segment BLI sub-TLV is expressed as below:¶
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes:
Tunnel Encaps Attribute (23)
Tunnel Type: SR Policy
Binding SID
Preference
Priority
Policy Name
Explicit NULL Label Policy (ENLP)
Segment List
Shared BLI
Weight
Segment
Segment
...
...
¶
When a candidate path of SR Policy is a bounded-latency routing path, the originating node of SR policy MUST include the associated bounded latency information in the BGP Tunnel Encapsulation Attribute of the BGP SR Policy. The other fields and attributes in BGP SR Policy should follows the mechanism as defined in[I-D.ietf-idr-segment-routing-te-policy].¶
When a BGP speaker receives an SR Policy which is acceptable and usable according to the rules as defined in[I-D.ietf-idr-segment-routing-te-policy] , and the SR Policy candidate path selected as the best candidate path is a bounded-latency path, the receiver node of the SR Policy MUST encapsulate the specific bounded latency information to the header of packets steered to the SR Policy. For SR Policy with IPv6 data plane and MPLS data plane, the possible approach is to encapsulate the BLI to the packet using the mechanism defined in[I-D.yzz-detnet-enhanced-data-plane] and[I-D.geng-spring-sr-enhanced-detnet].¶
IANA is requested to make the assignment from the "BGP Tunnel Encapsulation Attribute sub-TLVs" registry as follows.¶
+-----------------+---------------------------------+----------------+ | Value | Name | Reference | +-----------------+---------------------------------+----------------+ | TBD1 | BLI List sub-TLV | This document | +-----------------+---------------------------------+----------------+ | TBD2 | Shared BLI sub-TLV | This document | +-----------------+---------------------------------+----------------+¶