Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPFCapitalonlinexiaohu.xu@capitalonline.netsriganeshkini@gmail.comCisco Systems, Inc.Eurovea Centre, Central 3Pribinova Street 10Bratislava81109Slovakiappsenak@cisco.comCisco Systems, Inc.BrusselsBelgiumcfilsfil@cisco.comCisco Systems, Inc.La RigourdiereCesson SevigneFranceslitkows@cisco.comNokiaAztec West Business ParkBristol740 Waterside DriveBS32 4UFUnited Kingdommatthew.bocci@nokia.com
RTG
LSRMultiprotocol Label Switching (MPLS) has defined a mechanism to load-balance
traffic flows using Entropy Labels (EL). An ingress Label
Switching Router (LSR) cannot insert ELs for packets going into a given
Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the
capability to process ELs, referred to as the Entropy Label Capability
(ELC), on that LSP. In addition, it would be useful for ingress LSRs
to know each LSR's capability for reading the maximum label stack depth
and performing EL-based load-balancing, referred to as Entropy Readable
Label Depth (ERLD). This document defines a mechanism to signal these two
capabilities using OSPFv2 and OSPFv3, and Border Gateway Protocol - Link
State (BGP-LS).Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 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
() 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
. Introduction
. Terminology
. Advertising ELC Using OSPF
. Advertising ELC Using OSPFv2
. Advertising ELC Using OSPFv3
. Advertising ERLD Using OSPF
. Signaling ELC and ERLD in BGP-LS
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Contributors
Authors' Addresses
Introduction describes a method to load-balance
Multiprotocol Label Switching (MPLS) traffic flows using Entropy Labels
(EL). It also introduces the concept of Entropy Label
Capability (ELC) and defines the signaling of this capability via MPLS
signaling protocols. Recently, mechanisms have been defined to signal
labels via link-state Interior Gateway Protocols (IGP) such as OSPFv2
and OSPFv3 .
This document defines a mechanism to signal the ELC using OSPFv2 and OSPFv3.In cases where Segment Routing (SR) is used with the MPLS data plane
(e.g., SR-MPLS ), it would be
useful for ingress LSRs to know each intermediate LSR's capability of
reading the maximum label stack depth and performing EL-based
load-balancing. This capability, referred to as Entropy Readable Label
Depth (ERLD) as defined in ,
may be used by ingress LSRs to determine the position of the EL label in
the stack, and whether it is necessary to insert multiple ELs at
different positions in the label stack. This document defines a
mechanism to signal the ERLD using OSPFv2 and OSPFv3.TerminologyThis memo makes use of the terms defined in and .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 when, and
only when, they appear in all capitals, as shown here.The key word OSPF is used throughout the document to refer to both OSPFv2 and
OSPFv3.Advertising ELC Using OSPFEven though ELC is a property of the node, in some cases it is advantageous
to associate and advertise the ELC with a prefix. In multi-area networks,
routers may not know the identity of the prefix originator in a remote area
or may not know the capabilities of such an originator. Similarly, in a multi-domain
network, the identity of the prefix originator and its capabilities may not be
known to the ingress LSR.If a router has multiple interfaces, the router MUST NOT announce ELC
unless all of its interfaces are capable of processing ELs.If the router supports ELs on all of its interfaces, it
SHOULD advertise the ELC with every local host prefix it
advertises in OSPF.Advertising ELC Using OSPFv2 defines the OSPFv2
Extended Prefix TLV to advertise additional attributes associated with
a prefix. The OSPFv2 Extended Prefix TLV includes a one-octet Flags
field. A new flag in the Flags field is used to signal the ELC for the
prefix:
0x20 - E-Flag (ELC Flag):
Set by the advertising router
to indicate that the prefix originator is capable of processing
ELs.
The ELC signaling MUST be preserved when an OSPF
Area Border Router (ABR) distributes information between areas. To do
so, an ABR MUST originate an OSPFv2 Extended Prefix
Opaque Link State Advertisement (LSA) including the
received ELC setting.When an OSPF Autonomous System Border Router (ASBR) redistributes
a prefix from another instance of OSPF or from some other protocol, it
SHOULD preserve the ELC signaling for the prefix if it
exists. To do so, an ASBR SHOULD originate an Extended
Prefix Opaque LSA including
the ELC setting of the redistributed prefix. The flooding scope of the
Extended Prefix Opaque LSA MUST match the flooding
scope of the LSA that an ASBR originates as a result of the
redistribution. The exact mechanism used to exchange ELC between
protocol instances on an ASBR is outside of the scope of this
document.Advertising ELC Using OSPFv3 defines the OSPFv3
PrefixOptions field to indicate capabilities associated with a
prefix. A new bit in the OSPFv3 PrefixOptions field is used to signal the
ELC for the prefix:
0x40 - E-Flag (ELC Flag):
Set by the advertising router to
indicate that the prefix originator is capable of processing ELs.
The ELC signaling MUST be preserved when an OSPFv3
Area Border Router (ABR) distributes information between areas. The
setting of the ELC Flag in the Inter-Area-Prefix-LSA or in the Inter-Area-Prefix TLV
, generated by an ABR,
MUST be the same as the value the ELC Flag associated
with the prefix in the source area.When an OSPFv3 Autonomous System Border Router (ASBR)
redistributes a prefix from another instance of OSPFv3 or from some
other protocol, it SHOULD preserve the ELC signaling
for the prefix if it exists. The setting of the ELC Flag in the
AS-External-LSA, Not-So-Stubby Area LSA (NSSA-LSA) ,
or in the External-Prefix TLV , generated by an ASBR, MUST be the
same as the value of the ELC Flag associated with the prefix in the
source domain. The exact mechanism used to exchange ELC between
protocol instances on the ASBR is outside of the scope of this
document.Advertising ERLD Using OSPFThe ERLD is advertised in a Node Maximum SID Depth (MSD) TLV using the ERLD-MSD type defined in .If a router has multiple interfaces with different capabilities of
reading the maximum label stack depth, the router MUST
advertise the smallest value found across all of its interfaces.The absence of ERLD-MSD advertisements indicates only that the advertising
node does not support advertisement of this capability.When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD sub-TLV
, it MUST be ignored.The considerations for advertising the ERLD are specified in
.Signaling ELC and ERLD in BGP-LSThe OSPF extensions defined in this document can be advertised via
BGP-LS (distribution of Link-State and TE information using BGP)
using existing BGP-LS TLVs.The ELC is advertised using the Prefix Attribute Flags TLV as defined in
.The ERLD-MSD is advertised using the Node MSD TLV as defined in
.IANA ConsiderationsIANA has completed the following actions for this document:
Flag 0x20 in the "OSPFv2 Extended Prefix TLV Flags" registry has been
allocated to the E-Flag (ELC Flag).
Bit 0x40 in the "OSPFv3 Prefix Options (8 bits)" registry has been
allocated to the E-Flag (ELC Flag).
Security ConsiderationsThis document specifies the ability to advertise additional node
capabilities using OSPF and BGP-LS. As such, the security
considerations as described in , , , , , , , and are
applicable to this document.Incorrectly setting the E-Flag during origination, propagation, or
redistribution may lead to poor or no load-balancing of the MPLS traffic
or to the MPLS traffic being discarded on the egress node.
Incorrectly setting of the ERLD value may lead to poor or no load-balancing of the
MPLS traffic.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.OSPF for IPv6This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK]The Use of Entropy Labels in MPLS ForwardingLoad balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK]OSPFv2 Prefix/Link Attribute AdvertisementOSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328. This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links. Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs. The OSPFv2 Opaque LSAs are optional and fully backward compatible.North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGPIn a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).Extensions to OSPF for Advertising Optional Router CapabilitiesIt is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.OSPFv3 Link State Advertisement (LSA) ExtensibilityOSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described.This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support.Signaling Maximum SID Depth (MSD) Using OSPFThis document defines a way for an Open Shortest Path First (OSPF) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. This document only refers to the Signaling MSD as defined in RFC 8491, but it defines an encoding that can support other MSD types. Here, the term "OSPF" means both OSPFv2 and OSPFv3.Entropy Label for Source Packet Routing in Networking (SPRING) TunnelsSegment Routing (SR) leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions, called segments. Segment Routing can be applied to the Multiprotocol Label Switching (MPLS) data plane. Entropy labels (ELs) are used in MPLS to improve load-balancing. This document examines and describes how ELs are to be applied to Segment Routing MPLS.Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link StateThis document defines a way for a Border Gateway Protocol - Link State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity.Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network.Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment RoutingSignaling Entropy Label Capability and Entropy Readable Label Depth Using IS-ISInformative ReferencesSegment Routing with the MPLS Data PlaneSegment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS).OSPF Extensions for Segment RoutingSegment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).This document describes the OSPFv2 extensions required for Segment Routing.OSPFv3 Extensions for Segment RoutingSegment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).This document describes the OSPFv3 extensions required for Segment Routing with the MPLS data plane.AcknowledgementsThe authors would like to thank ,
, ,
, , , , and
for their valuable comments.ContributorsThe following people contributed to the content
of this document and should be considered coauthors:NokiaAntwerpBelgiumgunter.van_de_velde@nokia.comNokiaBelgiumwim.henderickx@nokia.comArrcusUnited States of Americakeyur@arrcus.comAuthors' AddressesCapitalonlinexiaohu.xu@capitalonline.netsriganeshkini@gmail.comCisco Systems, Inc.Eurovea Centre, Central 3Pribinova Street 10Bratislava81109Slovakiappsenak@cisco.comCisco Systems, Inc.BrusselsBelgiumcfilsfil@cisco.comCisco Systems, Inc.La RigourdiereCesson SevigneFranceslitkows@cisco.comNokiaAztec West Business ParkBristol740 Waterside DriveBS32 4UFUnited Kingdommatthew.bocci@nokia.com