IGP Flexible Algorithms (Flex-Algorithm)
In IP NetworksJuniper NetworksElnath-Exora Business Park SurveyBangaloreKarnataka560103Indiabwilliam@juniper.netJuniper NetworksElnath-Exora Business Park SurveyBangaloreKarnataka560103Indiashraddha@juniper.netJuniper NetworksElnath-Exora Business Park SurveyBangaloreKarnataka560103Indiapkaneria@juniper.netJuniper NetworksElnath-Exora Business Park SurveyBangaloreKarnataka560103Indiamrajesh@juniper.netJuniper Networks2251 Corporate Park DriveHerndon20171VirginiaUSArbonica@juniper.netCisco SystemsApollo Business CenterMlynske nivy 43Bratislava82109Slovakiappsenak@cisco.com
Routing Area
LSR Working GroupISISDraftAn IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute
constraint-based paths. The base IGP Flex-Algorithm specification
describes how it is used with Segment Routing (SR) data planes - SR MPLS and
SRv6.This document extends IGP Flex-Algorithm, so that it can be used with
regular IPv4 and IPv6 forwarding.An IGP Flex-Algorithm as specified in computes a constraint-based path to:
All Flex-Algorithm specific Prefix Segment Identifiers (SIDs)
.All Flex-Algorithm specific SRv6 Locators .Therefore, Flex-Algorithm cannot be deployed in the absence of
SR or SRv6.This document extends Flex-Algorithm, allowing it to compute paths
to IPv4 and IPv6 prefixes.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 System Architecture for the 5G System
describes the N3 interface between gNodeB and UPF (User Plane Function).Mobile networks are becoming more and more IP centric. Each end-user session from
a gNodeB can be destined to a specific UPFs (User Plane Function) based on the
session requirements. For example, some sessions require high bandwidth, others
need to be routed along the lowest latency path. Each UPF is assigned a unique
IP address. As a result, traffic for different sessions is destined to a different
destination IP address.The IP address allocated to the UPF can be associated with an algorithm. The mobile
user traffic is then forwarded along the path based on the algorithm-specific
metric and constraints. As a result, traffic can be sent over a path that is optimized
for minimal latency or highest bandwidth. This mechanism is used to achieve SLA
(Service Level Agreement) appropriate for a user session.To guarantee loop-free forwarding, all routers that participate in a
Flex-Algorithm MUST agree on the Flex-Algorithm Definition (FAD).Selected nodes within the IGP domain MUST advertise FADs as described
in Sections 5, 6, and 7 of .A node may use various algorithms when calculating paths to nodes and
prefixes. Algorithm values are defined in the IGP Algorithm Type Registry .A node MUST participate in a Flex-Algorithm to be:Able to compute path for such Flex-AlgorithmPart of the topology for such Flex-AlgorithmFlex-Algorithm participation MUST be advertised for each
Flex-Algorithm data-plane independently, as specified in
. Using Flex-Algorithm for
regular IPv4 and IPv6 prefixes represents an independent Flex-Algorithm
data-plane, and as such, the Flex-Algorithm participation for the IP Flex-Algorithm
data-plane MUST be signalled independently of any other Flex-Algorithm
data-plane (e.g., SR).All routers in an IGP domain participate in default algorithm 0.
Advertisement of participation in IP Flex-Algorithm does not impact
the router participation in default algorithm 0.
Advertisement of participation in IP Flex-Algorithm does not impact
the router participation signaled for other data-planes. For example,
it is possible that a router participates in a particular flex-algo
for the IP datapalne but does not participate in the
same flex-algo for the SR data-plane.The following sections describe how the IP Flex-Algorithm participation
is advertised in IGP protocols.The IS-IS IP Algorithm Sub-TLV is a sub-TLV of the
IS-IS Router Capability TLV and has the following format:
Type: IP Algorithm Sub-TLV (Value 29)Length: VariableAlgorithm (1 octet): Value from 128 to 255.The IP Algorithm Sub-TLV MUST be propagated throughout the level
and MUST NOT be advertised across level boundaries. Therefore, the S
bit in the Router Capability TLV, in which the IP Algorithm Sub-TLV is
advertised, MUST NOT be set.The IP Algorithm Sub-TLV is optional. It MUST NOT be advertised
more than once at a given level. A router receiving multiple IP
Algorithm sub-TLVs from the same originator MUST select the first
advertisement in the lowest-numbered LSP and subsequent instances of
the IP Algorithm Sub-TLV MUST be ignored.The use of the IP Algorithm Sub-TLV to advertise support for algorithms
outside the Flex-Algorithm range (128-255) is outside the
scope of this document.The IP Flex-Algorithm participation advertised in the IS-IS IP Algorithm
Sub-TLV is topology independent. When a router advertises
participation in the IS-IS IP Algorithm Sub-TLV, the participation applies
to all topologies in which the advertising node participates.The OSPF IP Algorithm TLV is a top-level TLV of the
Router Information Opaque LSA and has the
following format: Type: IP Algorithm TLV (Value TBD1 by IANA)Length: VariableAlgorithm (1 octet): Value from 128 to 255.The IP Algorithm TLV is optional. It MUST only be advertised once
in the Router Information LSA.When multiple IP Algorithm TLVs are received from a given router,
the receiver MUST use the first occurrence of the TLV in the Router
Information LSA. If the IP Algorithm TLV appears in multiple Router Information
LSAs that have different flooding scopes, the IP Algorithm TLV in the Router
Information LSA with the area-scoped flooding scope MUST be used. If the
IP Algorithm TLV appears in multiple Router Information LSAs that have the same
flooding scope, the IP Algorithm TLV in the Router Information LSA with the
numerically smallest Instance ID (Opaque ID for OSPFv2 or Link State ID for OSPFv3)
MUST be used and subsequent instances of the IP Algorithm TLV MUST be ignored.The Router Information LSA can be advertised at any of the defined flooding
scopes (link, area, or Autonomous System (AS)). For the purpose of IP
Algorithm TLV advertisement, area or Autonomous System scoped flooding is REQUIRED.
The AS flooding scope SHOULD NOT be used unless local configuration policy
on the originating router indicates domain-wide flooding.The IP Flex-Algorithm participation advertised in the OSPF IP Algorithm
TLV is topology independent. When a router advertises participation in
OSPF IP Algorithm TLV, the participation applies to all topologies in
which the advertising node participates.To be able to associate the prefix with the Flex-Algorithm, the
existing prefix reachability advertisements cannot be used, because
they advertise the prefix reachability in default algorithm 0. Instead,
new IP Flex-Algorithm reachability advertisements are defined in IS-IS
and OSPF.The M-flag in the FAD is not applicable to IP Algorithm Prefixes. Any IP
Algorithm Prefix advertisement includes the Algorithm and Metric fields.
When an IP Algorithm Prefix is advertised between areas or domains, the
metric field in the IP Algorithm Prefix advertisement MUST be used
irrespective of the M-flag in the FAD advertisement.The IPv4 Algorithm Prefix Reachability top-level TLV is defined for advertising IPv4 Flex-Algorithm
Prefix Reachability in IS-IS.This new TLV shares the sub-TLV space defined for TLVs Advertising Prefix
Reachability.The IS-IS IPv4 Algorithm Prefix Reachability TLV has the following
format: Type: IPv4 Algorithm Prefix Reachability TLV (Value 126).Length: Variable based on number of prefix entries encodedRsvd (4 bits): Reserved for future use. They MUST be set to
zero on transmission and MUST be ignored on receipt.MTID (12 bits): Multitopology Identifier as defined in
[RFC5120]. Note that the value 0 is legal.Followed by one or more prefix entries of the form:
Metric (4 octets): Metric information as defined in .Flags (1 octet): D-flag: When the Prefix is leaked from level-2 to level-1,
the D bit MUST be set. Otherwise, this bit MUST be clear.
Prefixes with the D bit set MUST NOT be leaked from level-1 to
level-2. This is to prevent looping.Algorithm (1 octet): Associated Algorithm from 128 to 255.Prefix Len (1 octet): Prefix length measured in bits.Prefix (variable length): Prefix mapped to Flex-Algorithm.Optional Sub-TLV-length (1 octet): Number of octets used by
sub-TLVsOptional sub-TLVs (variable length). If a router receives multiple IPv4 Algorithm Prefix Reachability
advertisements for the same prefix from the same originator, it
MUST select the first advertisement in
the lowest-numbered LSP and ignore any subsequent IPv4 Algorithm
Prefix Reachability advertisements for the same prefix.If a router receives multiple IPv4 Algorithm Prefix Reachability
advertisements for the same prefix, from different originators,
where all of them do not advertise the same algorithm, it MUST ignore all of them and
MUST NOT install any forwarding entries based on these
advertisements. This situation SHOULD be logged as an error.In cases where a prefix advertisement is received in both a IPv4
Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability TLV,
the IPv4 Prefix Reachability advertisement MUST be preferred when
installing entries in the forwarding plane.The IS-IS IPv6 Algorithm Prefix Reachability TLV is identical to the
IS-IS IPv4 Algorithm Prefix Reachability TLV, except that it has a
distinct type. The type is 127. If a router receives multiple IPv6 Algorithm Prefix Reachability
advertisements for the same prefix from the same originator, it
MUST select the first advertisement in
the lowest-numbered LSP and ignore any subsequent IPv6 Algorithm
Prefix Reachability advertisements for the same prefix.If a router receives multiple IPv6 Algorithm Prefix Reachability
advertisements for the same prefix, from different originators,
where all of them do not advertise the same algorithm, it MUST ignore all of them and
MUST NOT install any forwarding entries based on these
advertisements. This situation SHOULD be logged as an error.In cases where a prefix advertisement is received in both an IPv6
Prefix Reachability TLV and an IPv6 Algorithm Prefix Reachability TLV,
the IPv6 Prefix Reachability advertisement MUST be preferred when
installing entries in the forwarding plane.In cases where a prefix advertisement is received in both an IS-IS SRv6
Locator TLV and in IS-IS IPv6 Algorithm Prefix Reachability TLV, the receiver
MUST ignore both of them and MUST NOT install any forwarding entries based
on these advertisements. This situation SHOULD be logged as an error.A new Sub-TLV of the OSPFv2 Extended Prefix TLV is defined for
advertising IP Algorithm Prefix Reachability in OSPFv2, the OSPFv2 IP
Algorithm Prefix Reachability Sub-TLV.The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV has the
following format:Type (2 octets) : The value is TBD2.Length (2 octet): 8MT-ID (1 octet): Multi-Topology ID as defined in Algorithm (1 octet): Associated Algorithm from 128 to 255.Flags: (1 octet): The following flags are defined:
bit E: Same as bit E defined in section A.4.5 of .The remaining bits, are reserved for future use. They MUST be
set to zero on transmission and MUST be ignored on receipt.Reserved: (1 octets). SHOULD be set to 0 on transmission and
MUST be ignored on reception.Metric (4 octets): The algorithm-specific metric value. The metric
value of 0XFFFFFFFF MUST be considered as unreachable.An OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix
Reachability Sub-TLVs in the same OSPFv2 Extended Prefix TLV, MUST
select the first advertisement of this Sub-TLV and MUST ignore all
remaining occurences of this Sub-TLV in the OSPFv2 Extended Prefix
TLV.An OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix
Reachability TLVs for the same prefix, from different originators,
where all of them do not advertise the same algorithm, MUST ignore all of them and MUST NOT
install any forwarding entries based on these advertisements.
This situation SHOULD be logged as an error.In cases where a prefix advertisement is received in any of the
LSAs advertising the prefix reachability for algorithm 0 and in an OSPFv2
IP Algorithm Prefix Reachability Sub-TLV, only the prefix reachability
advertisement for algorithm 0 MUST be used and all occurences of the
OSPFv2 IP Algorithm Prefix Reachability Sub-TLV MUST be ignored.When computing the IP Algorithm Prefix reachability in OSPFv2, only information
present in the OSPFv2 Extended Prefix TLV MUST be used. There will not be any
information advertised for the IP Algorithm Prefix in any of the OSPFv2
LSAs that advertise prefix reachability for algorithm 0. For the IP Algorithm Prefix
the OSPFv2 Extended Prefix TLV is used to advertise the prefix reachability, unlike
for algorithm 0 prefixes, where the OSPFv2 Extended Prefix TLV is only used to advertise
additional attributes, but not the reachability itself.A new Sub-TLV of the OSPFv2 Extended Prefix TLV is defined for
advertising IP Forwarding Address, the OSPFv2 IP Forwarding Address Sub-TLV.The OSPFv2 IP Forwarding Address Sub-TLV has the
following format:Type (2 octets) : The value is TBD4.Length (2 octet): 4Forwarding Address: Same as defined in section A.4.5 of
.The OSPFv2 IP Forwarding Address Sub-TLV MUST NOT be used
for computing algorithm 0 prefix reachability and MUST be ignored for
algorithm 0 prefixes.The OSPFv2 IP Forwarding Address Sub-TLV is optional. If it is not present,
the forwarding address for computing the IP Algorithm Prefix reachability
is assumed to be equal to 0.0.0.0.The OSPFv2 IP Forwarding Address Sub-TLV is only applicable to Autonomous System
(AS) External and Not-So-Stubby Area (NSSA) External route types. If the
OSPFv2 IP Forwarding Address Sub-TLV is advertised in the OSPFv2 Extended
Prefix TLV that has the Route Type field set to any other type, the OSPFv2
IP Forwarding Address Sub-TLV MUST be ignored.The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV
is defined for advertisement of the IP Algorithm Prefix Reachability in OSPFv3.The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is a sub-TLV of
the following OSPFv3 TLVs defined in : Intra-Area-Prefix TLVInter-Area-Prefix TLVExternal-Prefix TLVThe format of OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is
shown below:Where:Type (2 octets): The value is TBD3.Length (2 octets): 8.Algorithm (1 octet): Associated Algorithm from 128 to 255.Reserved: (3 octets). SHOULD be set to 0 on transmission and
MUST be ignored on reception.Metric (4 octets): The algorithm-specific metric value. The metric
value of 0XFFFFFFFF MUST be considered as unreachable.When the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is
present, the NU-bit in the PrefixOptions field of the parent TLV MUST be set.
This is needed to prevent the OSPFv3 IP Algorithm Prefix Reachability advertisement
from contributing to the base algorithm reachability. If the NU-bit in the
PrefixOptions field of the parent TLV is not set, the OSPFv3 IP Algorithm
Prefix Sub-TLV MUST be ignored by the receiver.The metric value in the parent TLV is RECOMMENDED to be set to LSInfinity
. This recommendation is provided as a network troubleshooting
convenience; if it is not followed the protocol will still function correctly.An OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix
Reachability Sub-TLVs in the same parent TLV, MUST select the first
advertisement of this Sub-TLV and MUST ignore all remaining occurences
of this Sub-TLV in the parent TLV.An OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix
Reachability TLVs for the same prefix, from different originators,
where all of them do not advertise the same algorithm, MUST ignore all of them and MUST NOT
install any forwarding entries based on these advertisements.
This situation SHOULD be logged as an error.In cases where a prefix advertisement is received in any of the
LSAs advertising the prefix reachability for algorithm 0 and in an OSPFv3
OSPFv3 IP Algorithm Prefix Reachability Sub-TLV, only the prefix reachability
advertisement for algorithm 0 MUST be used and all occurences of the
OSPFv3 IP Algorithm Prefix Reachability Sub-TLV MUST be ignored.In cases where a prefix advertisement is received in both an OSPFv3 SRv6 Locator TLV
and in an OSPFv3 IP Algorithm Prefix Reachability Sub-TLV, the receiver
MUST ignore both of them and MUST NOT install any forwarding entries based
on these advertisements. This situation SHOULD be logged as an error. defines
the OSPF Flexible Algorithm ASBR Metric Sub-TLV (FAAM) that is used by
an OSPFv2 or an OSPFv3 ABR to advertise a Flex-Algorithm specific metric
associated with the corresponding ASBR LSA.As described in each data-plane signals
its participation independently. IP Flex-Algorithm participation is
signaled independent of Segment Routing (SR) Flex-Algorithm
participation. As a result, the calculated topologies for SR and IP
Flex-Algorithm could be different. Such difference prevents the usage
of FAAM for the purpose of the IP Flex-Algorithm.The OSPF IP Flexible Algorithm ASBR Metric (IPFAAM) Sub-TLV is
defined for the advertisement of the IP Flex-Algorithm specific metric
associated with an ASBR by the ABR.The IPFAAM Sub-TLV is a Sub-TLV of the: - OSPFv2 Extended Inter-Area ASBR TLV as defined in - OSPFv3 Inter-Area-Router TLV defined in The OSPF IPFAAM Sub-TLV has the following format:Type (2 octets): 2 (allocated by IANA) for OSPFv2, TBD5 for OSPFv3.Length (2 octets): 8.Algorithm (1 octet): Associated Algorithm from 128 to 255.Reserved: (3 octets). SHOULD be set to 0 on transmission and
MUST be ignored on reception.Metric (4 octets): The algorithm-specific metric value.The usage of the IPFAAM Sub-TLV is similar to the usage of the FAAM
Sub-TLV defined in , but it is
used to advertise IP Flex-Algorithm metric.An OSPF ABR MUST include the OSPF IPFAAM Sub-TLVs as part of the
ASBR reachability advertisement between areas for every IP
Flex-Algorithm in which it participates and the ASBR is reachable
in.The FAAM Sub-TLV as defined in
MUST NOT be used during IP Flex-Algorithm path calculation, the IPFAAM
Sub-TLV MUST be used instead.The IP Flex-Algorithm is considered as yet another data-plane of the
Flex-Algorithm as described in .Participation in the IP Flex-Algorithm is signalled as described in
and is specific to the IP Flex-Algorithm
data-plane.Calculation of IP Flex-Algorithm paths follows what is described in
. This computation uses the IP
Flex-Algorithm data-plane participation and is independent of the Flex-Algorithm
calculation done for any other Flex-Algorithm data-plane (e.g., SR,
SRv6).The IP Flex-Algorithm data-plane only considers participating nodes
during the Flex-Algorithm calculation. When computing paths for a given
Flex-Algorithm, all nodes that do not advertise participation for the IP
Flex-Algorithm, as described in , MUST be
pruned from the topology.The IP Algorithm Prefix Reachability advertisement as described in includes the MTID value that associates the
prefix with a specific topology. Algorithm Prefix Reachability
advertisement also includes an Algorithm value that explicitly
associates the prefix with a specific Flex-Algorithm. The paths to the
prefix MUST be calculated using the specified Flex-Algorithm in the
associated topology.Forwarding entries for the IP Flex-Algorithm prefixes advertised in
IGPs MUST be installed in the forwarding plane of the receiving IP
Flex-Algorithm prefix capable routers when they participate in the
associated topology and algorithm. Forwarding entries for IP
Flex-Algorithm prefixes associated with Flex-Algorithms in which the
node is not participating MUST NOT be installed in the forwarding
plane.IGP Flex-Algorithm can be used by many data-planes. The original
specification was done for SR and SRv6, this specification adds IP as
another data-plane that can use IGP Flex-Algorithm. Other data-planes
may be defined in the future. This section provides some details about
the coexistence of the various data-planes of an IGP Flex-Algorithm.Flex-Algorithm definition (FAD), as described in , is data-plane independent and is
used by all Flex-Algorithm data-planes.Participation in the Flex-Algorithm, as described in , is data-plane specific.Calculation of the flex-algo paths is data-plane specific and uses
data-plane specific participation advertisements.Data-plane specific participation and calculation guarantee that the
forwarding of the traffic over the Flex-Algorithm data-plane specific
paths is consistent between all nodes that apply the IGP Flex-Algorithm
to the data-plane.Multiple data-planes can use the same Flex-Algorithm value at the
same time and, and as such, share the FAD for it. For example, SR-MPLS and
IP can both use a common Flex-Algorithm. Traffic for SR-MPLS will be
forwarded based on Flex-algorithm specific SR SIDs. Traffic for IP
Flex-Algorithm will be forwarded based on Flex-Algorithm specific prefix
reachability advertisements. Note that for a particular Flex-Algorithm, for
a particular IP prefix, there will only be path(s) calculated and installed
for a single data-plane.In many networks where IGP Flexible Algorithms are deployed, IGP
restoration will be fast and additional protection mechanisms will not
be required. IGP restoration may be enhanced by Equal Cost Multipath
(ECMP).In other networks, operators can deploy additional protection
mechanisms. The following are examples:Loop Free Alternates (LFA)Remote Loop Free Alternates (R-LFA)
LFA and R-LFA computations MUST be restricted to the flex-algo
topology and the computed backup nexthops should be programmed for the
IP flex-algo prefixes.This specification updates the OSPF Router Information (RI) TLVs
Registry as follows:ValueTLV NameReferenceTBD1IP Algorithm TLVThis Document This document also updates the IS-IS "Sub-TLVs for TLV 242" registry as
follows:ValueTLV NameReference29IP Algorithm Sub-TLVThis Document This document also updates the "IS-IS TLV Codepoints Registry"
registry as follows:ValueTLV NameIIHLSPSNPPurgeReference126IPv4 Algorithm Prefix Reachability TLVNYNNThis document, 127IPv6 Algorithm Prefix Reachability TLVNYNNThis document, Since the above TLVs share the sub-TLV space managed in the "IS-IS
Sub-TLVs for TLVs Advertising Prefix Reachability" registry, IANA is
requested to add "IPv4 Algorithm Prefix Reachability TLV (126)" and
"IPv6 Algorithm Prefix Reachability TLV (127)" to the list of TLVs in
the description of that registry.In addition, columns headed '126' and '127' are added to that registry,
as follows:This document updates the "OSPFv2 Extended Prefix TLV Sub-TLVs"
registry as follows:ValueTLV NameReferenceTBD2OSPFv2 IP Algorithm Prefix Reachability Sub-TLVThis Document, TBD4OSPFv2 IP Forwarding Address Sub-TLVThis Document, This document creates a new registry under "Open Shortest Path First v2 (OSPFv2)
Parameters" registry, called "IP Algorithm Prefix Reachability Sub-TLV Flags". The
new registry defines the bits in the 8-bit Flags field in the OSPFv2 IP Algorithm
Prefix Reachability Sub-TLV (). New bits can
be allocated via IETF Review or IESG Approval Bit #NameReference0bit EThis Document, 1-7ReservedThis Document, This document updates the "OSPFv3 Extended-LSA Sub-TLVs" registry as
follows:ValueTLV NameReferenceTBD3OSPFv3 IP Algorithm Prefix Reachability Sub-TLVThis Document, TBD5OSPFv3 IP Flexible Algorithm ASBR Metric Sub-TLVThis Document, This document updates the "OSPFv2 Extended Inter-Area ASBR Sub-TLVs"
registry as follows:ValueTLV NameReference2OSPF IP Flexible Algorithm ASBR Metric Sub-TLVThis Document, This document inherits security considerations from .This document adds one new way to disrupt IGP networks that are using
Flex-Algorithm: an attacker can suppress reachability for a given
prefix whose reachability is advertised by a legitimate node for a
particular IP Flex-Algorithm X, by advertising the same prefix in
Flex-Algorithm Y from another, malicious node. (To see why this is,
consider, for example, the rule given in the second-last paragraph of
).This attack can be addressed by the existing security extensions, as
described in and for IS-IS,
in and for OSPFv2, and in
and for OSPFv3.If a node that is authenticated is taken over by an attacker, such a
rogue node can perform the attack described above. Such an attack is
not preventable through authentication, and it is not different from
advertising any other incorrect information through IS-IS or OSPF.Thanks to Bruno Decraene for his contributions to this document.
Special thanks to Petr Bonbon Adamec of Cesnet for supporting
interoperability testing.Intermediate system to Intermediate system routing
information exchange protocol for use in conjunction with the
Protocol for providing the Connectionless-mode Network Service (ISO
8473)International Organization for
StandardizationSystem Architecture for 5G System; Stage 2, 3GPP TS 23.501 v16.4.0
3rd Generation Partnership Project (3GPP)
Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV)IANA