]>
Flexible Algorithms: Bandwidth, Delay, Metrics and ConstraintsJuniper Networks Inc.Exora Business ParkBangaloreKA560103Indiashraddha@juniper.netJuniper Networks Inc.bwilliam@juniper.netJuniper Networks Inc.mrajesh@juniper.netOrangebruno.decraene@orange.comCisco Systemsppsenak@cisco.comJuniper Networks Inc.tony.li@tony.li
Routing
SPRINGASIGP
Many networks configure the link metric relative to the link capacity.
High bandwidth traffic gets routed as per the link capacity. Flexible
algorithms provide mechanisms to create constraint based paths in an IGP.
This draft documents a generic metric type and
set of bandwidth related constraints to be used in Flexible Algorithms.
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. High bandwidth traffic such as residential Internet traffic and
machine-to-machine elephant flows benefit from using high capacity
links. Accordingly, many network operators define a link's metric
relative to its capacity to help direct traffic to higher bandwidth
links, but this is no guarantee that lower bandwidth links will be
avoided, especially in failure scenarios. To ensure that elephant
flows are only placed on high capacity links, it would be useful to
explicitly exclude the high bandwidth traffic from utilizing links
below a certain capacity. A Flex-Algorithm
is defined as a set of parameters consisting of
calculation-type, metric-type, and a set of constraints to allow
operators to have more control over the network path computation. In
this document, we define further extensions to Flex-Algorithm that
will allow operators additional control over their traffic flows,
especially with respect to bandwidth constraints. Historically, IGPs have done path computation by minimizing the
sum of the link metrics along the path from source to
destination. While the metric has been administratively defined,
implementations have defaulted to a metric that is inversely
proportional to link bandwidth. This has driven traffic to higher
bandwidth links and has required manual metric manipulation to
achieve the desired loading of the network.Over time, with the addition of different traffic types, the need
for alternate types of metrics has evolved. Flex-Algorithm
already supports using the minimum link delay and the
administratively assigned traffic-engineering metrics in path
computation. However, it is clear that additional metrics may be of
interest in different situations. A network operator may seek to
minimize their operational costs and thus may want a metric that
reflects the actual fiscal costs of using a link. Other traffic
may require low jitter, leading to an entirely different set of
metrics. With Flex-Algorithm, all of these different metrics, and
more, could be used concurrently on the same network.In some circumstances, path computation constraints, such as
administrative groups, can be used to ensure that traffic avoids
particular portions of the network. These strict constraints are
appropriate when there is an absolute requirement to avoid parts of
the topology, even in failure conditions. If, however, the
requirement is less strict, then using a high metric in a portion
of the topology may be more appropriate. This document defines a family of generic metrics that can advertise
various types of administratively assigned metrics. This document proposes
standard metric-types which have specific semantics and require
to be standardized.
This document also proposes user defined metric-types where specifics are
not defined, so that administrators are free to assign semantics as
they see fit.In , this document specifies a
new bandwidth based metric
type to be used with Flex-Algorithm and other applications.
defines additional
Flexible Algorithm Definition (FAD)
constraints that allow the network
administrator to preclude the use of low bandwidth links or high
delay links.
defines mechanisms to automatically calculate link metrics based on
the parameters defined in the FAD and the advertised Maximum Link Bandwidth
of each link. This is advantageous because administrators can change their
criteria for metric assignment centrally, without individual
modification of each link metric throughout the network. The procedures
described in this document are intended to assign a metric to a link based on
the total link capacity and they are not intended to update the metric based
on actual traffic flow. Thus, the procedures described in this document are not a
replacement to the capability of a PCE which has a dynamic view of
the network and provides real-time bandwidth management or a distributed bandwidth
management protocol. IS-IS and OSPF advertise a metric for each link in their respective
link state advertisements. Multiple metric types are already supported.
Administratively assigned metrics are described in the original OSPF
and IS-IS specifications. The Traffic Engineering Default Metric
is defined in and
and the Min Unidirectional delay metric is defined in
and .
Other metrics, such as jitter, reliability, and fiscal cost may be
helpful, depending on the traffic class. Rather than attempt to
enumerate all possible metrics of interest, this document specifies
a generic mechanism for advertising metrics.
Each generic metric advertisement is on a per-link and per-metric
type basis. The metric advertisement consists of a metric type
field and a value for the metric. The metric type field is
assigned by the "IGP metric type" IANA registry. Metric types
0-127 are standard metric types as assigned by IANA. This document
further specifies a user-defined metric type space of metric types
128-255. These are user defined and can be assigned by an operator
for local use.
Implementations MUST support sending and receiving generic metric
sub-TLV in ASLA encodings as well as in the TLV 22/extended link LSA/TE-LSAs.
The usage of a generic metric by an individual application is subject to the same
rules that apply to other link attributes defined in respective standards.The IS-IS Generic Metric sub-TLV specifies the link metric for a given
metric type. Typically, this metric is assigned by a
network administrator.
The Generic Metric sub-TLV is advertised in the TLVs/sub-TLVs below:TLV-22 (Extended IS reachability) TLV-222 (MT-ISN) TLV-23 (IS Neighbor Attribute) TLV-223 (MT IS Neighbor Attribute) TLV-141 (inter-AS reachability information) sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of
TLV 22/222/23/223/141
The Generic Metric sub-TLV MAY be advertised multiple times.
For a particular metric type,
the Generic Metric sub-TLV MUST be advertised only once for a link
when advertised in TLV 22, 222, 23, 223 and 141.
When Generic metric sub-TLV is advertised in ASLA,
each metric type MUST be advertised only once per-application for a link.
If there are multiple Generic Metric sub-TLVs advertised for a link
for the same metric type (and same application in case of ASLA)
in one or more received LSPDUs, advertisement in the lowest numbered fragment
MUST be used and the subsequent instances MUST be ignored.
If the metric type indicates a standard
metric type for which there are other advertisement mechanisms
(e.g., the IGP metric, the Min Unidirectional Link Delay, or the
Traffic Engineering Default Metric), the
Generic Metric advertisement MUST be ignored.
A metric value of
0xFFFFFF is considered as maximum link metric and a link having
this metric value MUST be used during Flex-algorithm calculations
as a last resort link as described in sec 15.3 of .
A link can be made unusable by Flex-algorithm by leaving out Generic metric
advertisement of the particular metric-type that the Flex-algorithm
uses as described in .
The OSPF Generic Metric sub-TLV specifies the link metric for a given
metric type. Typically, this metric is assigned by a
network administrator.
The Generic Metric sub-TLV is advertised in the TLVs below: sub-TLV of the OSPF Link TLV of OSPF extended Link LSA . sub-TLV of TE Link TLV (2) of OSPF TE LSA .sub-TLV of the Router-Link TLV in the E-Router-LSA in OSPFv3
. sub-sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV .The Generic Metric sub-TLV is TLV type TBD2 (IANA), and is eight
octets in length.
The Generic Metric sub-TLV MAY be advertised multiple times.
For a particular metric type, the Generic Metric sub-TLV MUST be
advertised only once for a link when advertised in the
OSPF Link TLV of Extended Link LSA,
the Link TLV of TE LSA and the sub-TLV of the
Router-Link TLV in the E-Router-LSA Router-Link TLV in OSPFv3.
When Generic Metric sub-TLV is advertised as sub-sub-TLV of
ASLA, it MUST be advertised only once per-application for a link.
If there are multiple Generic Metric
sub-TLVs advertised for a link for the same metric type
in a received LSA, the first instance MUST be used and
the subsequent instances MUST be ignored.If the
metric type indicates a standard
metric type for which there are other advertisement mechanisms
(e.g., the IGP metric, the Min Unidirectional Link Delay, or the
Traffic Engineering Default Metric), the
Generic Metric advertisement MUST be ignored.A metric value of
0xFFFFFFFF is considered as maximum link metric and a link having
this metric value MUST be used during Flex-algorithm calculations
as a last resort link as described in sec 15.3 of .A link can be made unusable by Flex-algorithm by leaving out Generic metric
advertisement of the particular metric-type that the Flex-algorithm
uses as described in .Generic Metric can be used by Flex-Algorithms
by specifying the metric type in the
Flexible Algorithm Definitions. When Flex-Algorithms is used in a multi-area network,
defines the Flexible Algorithm Prefix Metric (FAPM)
sub-TLV that carries
the Flexible-Algorithm-specific metric. Metrics carried in FAPM will be equal
to the metric to reach the prefix for that Flex-Algorithm in its
source area or domain. When Flex-Algorithm uses
Generic metric, the same procedures as described in section 13 of
are used to send and process FAPM sub-TLV.
In networks that carry elephant flows, directing an elephant flow
down a low-bandwidth link would be catastrophic. Thus, in the
context of Flex-Algorithm, it would be useful to be able to
constrain the topology to only those links capable of supporting a
minimum amount of bandwidth.If the capacity of a link is constant, this can already be achived
through the use of administrative groups. However, when a layer-3
link is actually a collection of layer-2 links (LAG/layer-2
Bundle), the link bandwidth will vary based on the set of active
constituent links. This could be automated by having an
implementation vary the advertised administrative groups based on
bandwidth, but this seems unnecessarily complex and expressing this
requirement as a direct constraint on the topology seems
simpler. This is also advantageous if the minimum required
bandwidth changes, as this constraint would provide a single
centralized, coordinated point of control.To satify this requirement, this document defines an
Exclude Minimum Bandwidth
constraint. When this constraint is advertised in a FAD,
a link will be pruned from the Flex-Algorithm topology if the
link's advertised Maximum Link Bandwidth is below the advertised
Minimum Bandwidth value.Similarly, this document defines an Exclude Maximum Link Delay
constraint. Delay is an important consideration in High Frequency
Trading applications, networks with transparent L2 link recovery,
or in satellite networks, where link delay may fluctuate.
Mechanisms already exist to measure the link delay dynamically and
advertise it in the IGP. Networks that employ dynamic link-delay
measurement, may want to exclude links that have a delay over a
given threshold.
IS-IS Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) is a
sub-TLV of the IS-IS FAD sub-TLV. It has the following format:
The FAEMB sub-TLV MUST appear at most once in the FAD sub-TLV.
If it appears more than once, the IS-IS FAD sub-TLV MUST be
ignored by the receiver. The Minimum bandwidth advertised in FAEMB sub-TLV MUST be compared with
Maximum Link Bandwidth advertised in sub-sub-TLV 9 of ASLA sub-TLV .
If L-Flag is set in the ASLA sub-TLV, the Minimum bandwidth advertised in FAEMB
sub-TLV MUST be compared with Maximum Link Bandwidth as
advertised in the sub-TLV 9 of the TLV
22/222/23/223/141 as defined in
Section 4.2. If the Maximum Link Bandwidth is lower than the Minimum
link bandwidth advertised in FAEMB sub-TLV,
the link MUST be excluded from the Flex-Algorithm topology.
If a link does not have the Maximum Link Bandwidth advertised but the
FAD contains this sub-TLV, then that link
MUST NOT be excluded from the topology based on the Minimum
Bandwidth constraint.
IS-IS Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) is a
sub-TLV of the IS-IS FAD sub-TLV. It has the following format.
The FAEMD sub-TLV MUST appear only once in the FAD sub-TLV.
If it appears more than once, the IS-IS FAD sub-TLV MUST be
ignored by the receiver.The Maximum link delay advertised in FAEMD sub-TLV MUST be compared with
Min Unidirectional Link Delay advertised in sub-sub-TLV 34 of ASLA sub-TLV .
If the L-Flag is set in the ASLA sub-TLV, the Maximum link delay advertised in FAEMD
sub-TLV MUST be compared with Min Unidirectional Link Delay as
advertised by the sub-TLV 34 of the TLV
22/222/23/223/141 as defined in
Section 4.2. If the Min Unidirectional Link Delay value is higher than the
Maximum link delay advertised in FAEMD sub-TLV, the link MUST be
excluded from the Flex-Algorithm topology.
If a link does not have the Min Unidirectional Link Delay advertised but
the FAD contains this sub-TLV, then that link MUST NOT be
excluded from the topology based on the Maximum Delay constraint.
OSPF Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) is a
sub-TLV of the OSPF FAD TLV. It has the following format:
The FAEMB sub-TLV MUST only appear once in the FAD sub-TLV.
If it appears more than once, the OSPF FAD TLV MUST be
ignored by the receiver.
The Maximum Link Bandwidth as advertised in the Extended Link TLV
in the Extended Link Opaque LSA in OSPFv2
or as a sub-TLV
of the Router-Link TLV of the E-Router-LSA Router-Link TLV in
OSPFv3
MUST be compared against the Minimum bandwidth advertised in FAEMB sub-TLV.
If the link bandwidth is lower than the Minimum bandwidth advertised in FAEMB sub-TLV,
the link MUST be excluded from the Flex-Algorithm topology.
If a link does not have the Maximum Link Bandwidth advertised
but the FAD contains this sub-TLV, then that link MUST be included in the
topology and proceed to apply further pruning rules for the link.
The OSPF Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) is a
sub-TLV of the OSPF FAD TLV. It has the following format.
The FAEMD sub-TLV MUST only appear once in the OSPF FAD TLV.
If it appears more than once, the OSPF FAD TLV MUST be
ignored by the receiver.
The Min Delay value advertised via the Min/Max Unidirectional Link Delay
of ASLA sub-TLV , MUST be compared against the Maximum delay
advertised in the FAEMD sub-TLV. If the Min Unidirectional Link Delay is higher
than the Maximum delay advertised in the FAEMD sub-TLV, the link MUST be
excluded from the Flex-Algorithm topology. If the
Min/Max Unidirectional Link Delay is not aadvertised for a link but
the FAD contains this sub-TLV,then then that link MUST NOT be
excluded from the topology based on the Maximum Delay constraint.
Historically, IGP implementations have made default metric
assignments based on link bandwidth. This has proven to be useful,
but has suffered from having different defaults across
implementations and from the rapid growth of link bandwidths. With
Flex-Algorithm, the network administrator can define a function
that will produce a metric for each link and have each node
automatically compute each link's metric based its bandwidth.This document defines a standard metric type for this purpose
called the "Bandwidth Metric". The Bandwidth Metric MAY be
advertised in the Generic Metric sub-TLV with the metric type set
to "Bandwidth Metric". IS-IS and OSPF will advertise this type
of metric in their link advertisements. Bandwidth metric is a link
attribute and for the advertisement and processing of this attribute for
Flex-algorithm, MUST follow the the section 12 of
Flex-Algorithm uses this
metric type by specifying the bandwidth metric as the metric type
in a FAD TLV. A FAD TLV may also specify an automatic computation
of the bandwidth metric based on a link's advertised bandwidth. An
explicit advertisement of a link's bandwidth metric using the
Generic Metric sub-TLV overrides this automatic computation.
The automatic bandwidth metric calculation sub-TLVs are advertised
in the FAD TLV and these parameters are applicable to applications
such as Flex-algorithm that make use of the FAD TLV.
Networks which are designed to be highly regular and follow uniform
metric assignment may want to simplify their operations by
automatically calculating the bandwidth metric. When
a FAD advertises the metric type as Bandwidth Metric and the link does
not have the Bandwidth Metric advertised, automatic metric derivation
can be used with additional FAD constraint advertisement as
described in this section. If a link's bandwidth changes, then the delay in learning about the
change may create the possibility of micro-loops in the
topology. This is no different from the IGP's susceptibility to
micro-loops during a metric change. The micro-loop avoidance
procedures described in
or any other mechanism as described in the framework
can be used to avoid micro-loops when the automatic metric
calculation is deployed. Computing the metric between adjacent systems based on bandwidth
becomes more complex in the face of parallel adjacencies. If there
are parallel adjacencies between systems, then the bandwidth
between the systems is the sum of the bandwidth of the parallel
links. This is somewhat more complex to deal with, so there is an
optional mode for computing the aggregate bandwidth. In simple mode, the Maximum Link Bandwidth of a single layer-3 link
is used to derive the metric. This mode is suitable for
deployments that do not use parallel layer-3 links. In this case,
the computation of the metric is straightforward.
If a layer-3 link is composed of a layer-2 bundle, then the link
bandwidth is the sum of the bandwidths of the working components
and may vary with layer-2 link failures. The simple mode of metric calculation may not work well when there
are multiple parallel layer-3 interfaces between two nodes.
Ideally, the metric between two systems should be the same given
the same bandwidth, whether the bandwidth is provided by parallel
layer-2 links or parallel layer-3 links. To address this, in
Interface Group Mode, nodes MUST compute the aggregate bandwidth of
all parallel adjacencies, MUST derive the metric based on the
aggregate bandwidth, and MUST apply the resulting metric to each of
the parallel adjacencies. Note that a single elephant flow is normally
pinned to a single layer-3 interface. If the single layer-3 link
bandwidth is not sufficient for any single elephant flow, the mechanisms
to solve this issue are outside the scope of this document.
For exmple, in the above diagram, there are two parallel links
between B->C, C->F, F->D. Let us assume the link bandwidth is
uniform 10Gbps on all links. When bandwidth is used to derive the metric
for the links, the metric for each link will be
the same. Traffic from B to D will be forwarded B->E->D as
the metric will be lower. Since the
bandwidth is higher on the B->C->F->D path, the metric for that
path should be lower than the B->E->D path to attract the traffic on
B->C->F->D path. Interface
Group Mode should be preferred in cases where there are parallel layer-3
links.
In the interface group mode, every node MUST
identify the set of parallel links between a pair
of nodes based on IGP link advertisements
and MUST consider cumulative bandwidth of the
parallel links while arriving at the metric of each link. The parallel layer-3 links between two nodes may not have the
same bandwidth. In such cases the method described in interface group mode will
result in same metric being used for all the parallel links which may cause
undesired load-balancing on the links. In such cases, a device may locally
apply load-balancing factor relative to the link bandwidth on the ECMP nexthops.
In automatic metric calculation for simple and interface group mode,
Maximum Link Bandwidth of the links is used to derive the metric.
There are two types of automatic metric derivation methods. 1. Reference bandwidth method 2. Bandwidth thresholds method In many networks, the metric is inversely proportional to the link
bandwidth. The administrator or implementation selects a reference
bandwdith and the metric is derived by dividing the reference
bandwidth by the advertised Maximum Link Bandwidth. Advertising
the reference bandwidth in the FAD constraints allows the metric
computation to be done on every node for each link.
The metric is computed using reference bandwidth and the advertised link bandwidth.
Centralized control of this
reference bandwidth simplifies management in the case that the
reference bandwidth changes. In order to ensure that small
bandwidth changes do not change the link metric, it is useful to
define the granularity of the bandwidth that is of interest. The
link bandwidth will be truncated to this granularity before
deriving the metric.
For example,reference bandwidth = 1000G Granularity = 20G The derived metric is 10 for link bandwidth in the range 100G to 119G The reference bandwidth approach described above provides a uniform
metric value for a range of link bandwidths. In certain cases
there may be a need to define non-proportional metric values for
the varying ranges of link bandwidth. For example, bandwidths from
10G to 30G are assigned metric value 100, bandwidth from 30G to 70G
get a metric value of 50, and bandwidths greater than 70G have a
metric of 10. In order to support this, a staircase mapping based
on bandwidth thresholds is supported in the FAD. This
advertisement contains a set of threshold values and associated
metrics.
This section provides FAD constraint advertisement details for the
reference bandwidth method of metric calculation as described in
.
The Flexible Algorithm Definition Reference Bandwidth sub-TLV (FADRB sub-TLV) is
a sub-TLV of the IS-IS FAD sub-TLV. It has the following format:
The Granularity Bandwidth value ensures that the metric
does not change when there is a small
change in the link bandwidth.
The IS-IS FADRB sub-TLV MUST NOT appear more than once in an IS-IS FAD
sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV MUST be ignored
by the receiver. The value advertised in the Reference Bandwidth field MUST be non-zero.
If a zero value is advertised in the Reference Bandwidth Field in the IS-IS FADRB sub-TLV,
the sub-TLV MUST be ignored.
If a Generic Metric sub-TLV with Bandwidth metric
type is advertised for a link,
the Flex-Algorithm calculation MUST use the advertised Bandwidth Metric,
and MUST NOT use the automatically derived metric for that link.
In case of Interface Group Mode, if all the parallel links have been
advertised with the Bandwidth Metric, The individual link Bandwidth Metric
MUST be used. If only some links among the parallel links have the Bandwidth
Metric advertisement, the Bandwidth Metric for such links MUST be ignored and
automatic Metric calculation MUST be used to derive link metric.
If the calculated metric evaluates to zero, a metric of 1 MUST be used. If the calculated metric evaluates to a number greater than 0xFFFFFF,
it is set to 0xFFFFFF.
This section provides FAD constraint advertisement details for the
Bandwidth Thresholds method of metric calculation as
described in .
The Flexible Algorithm Definition Bandwidth Threshold sub-TLV (FADBT sub-TLV) is
a sub-TLV of the IS-IS FAD sub-TLV. It has the following format:
When G-flag is set, the cumulative bandwidth of the
parallel links is computed
as described in section . If G-flag is
not set, the advertised Maximum Link
Bandwidth is used.When the computed link bandwidth is less than Bandwidth Threshold
1, the MAX_METRIC value of 4,261,412,864 MUST be
assigned as the Bandwidth Metric on the link during the Flex-Algorithm SPF
calculation.When the computed link bandwidth is greater than or equal to Bandwidth
Threshold
1 and less than Bandwidth Threshold 2, Threshold Metric 1 MUST be
assigned as the Bandwidth Metric on the link during the Flex-Algorithm SPF
calculation.Similarly, when the computed link bandwidth is greater than or equal
to Bandwidth Threshold
2 and less than Bandwidth Threshold 3, Threshold Metric 2 MUST be
assigned as the Bandwidth Metric on the link during the Flex-Algorithm
SPF calculation.In general, when the computed link bandwidth is greater than or
equal to Bandwidth Threshold X AND less than Bandwidth Threshold X+1,
Threshold Metric X MUST be assigned as the Bandwidth Metric on the
link during the Flex-Algorithm SPF calculation.Finally, when the computed link bandwidth is greater than or equal
to Bandwidth Threshold N, then Threshold Metric N MUST be assigned
as the Bandwidth Metric on the link during Flex-Algorithm SPF
calculation.The IS-IS FADBT sub-TLV MUST NOT appear more than once in an IS-IS FAD
sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV MUST MUST
stop participating
in such flex-algorithm.A FAD MUST NOT contain both the FADBT sub-TLV and the FADRB sub-TLV. If both
these sub-TLVs are advertised in the same FAD for a Flexible
Algorithm, the FAD MUST be ignored by the receiver.If a Generic Metric sub-TLV with Bandwidth metric type is advertised
for a link, the Flex-Algorithm calculation MUST use the Bandwidth
Metric advertised on the link, and MUST NOT use the automatically
derived metric for that link.In case of Interface Group Mode, if all the parallel links
have been advertised with the Bandwidth Metric, The individual
link Bandwidth Metric MUST be used. If only some links among
the parallel links have the Bandwidth Metric advertisement,
the Bandwidth Metric for such links MUST be ignored and
automatic Metric calculation MUST be used to derive link metric.
The Flexible Algorithm Definition Reference Bandwidth sub-TLV (FADRB sub-TLV) is
a sub-TLV of the OSPF FAD TLV. It has the following format:
The Granularity Bandwidth value is used to ensure that the
metric does not change when there is a small
change in the link bandwidth.
The OSPF FADRB sub-TLV MUST NOT appear more than once in an OSPF FAD
TLV. If it appears more than once, the OSPF FAD TLV MUST be ignored
by the receiver.The value advertised in the Reference Bandwidth field MUST be non-zero.
If a zero value is advertised in the Reference Bandwidth Field in the OSPF FADRB sub-TLV,
the sub-TLV MUST be ignored.
If a Generic Metric sub-TLV with Bandwidth metric type is
advertised for a link, the Flex-Algorithm calculation MUST use
the advertised Bandwidth Metric
on the link, and MUST NOT use the automatically derived
metric for that link.In case of Interface Group Mode,
if all the parallel links have been advertised with the
Bandwidth Metric, The individual link Bandwidth Metric
MUST be used. If only some links among the parallel links
have the Bandwidth Metric advertisement, the Bandwidth Metric
for such links MUST be ignored and automatic Metric calculation
MUST be used to derive link metric.If the calculated metric evaluates to zero, a metric of 1 MUST be used. If the calculated metric evaluates to a number greater than 0xFFFFFFFF, it is set to 0xFFFFFFFF.
The Flexible Algorithm Definition Bandwidth Thresholds sub-TLV
(FADBT sub-TLV) is
a sub-TLV of the OSPF FAD TLV. It has the following format:
When G-flag is set, the cumulative bandwidth of the parallel links is
computed as described in section .
If G-flag is not set, the advertised Maximum Link
Bandwidth is used.When the computed link bandwidth is less than Bandwidth Threshold
1 , the MAX_METRIC value of 4,294,967,296 MUST be
assigned as the Bandwidth Metric on the link during
the Flex-Algorithm SPF calculation.When the computed link bandwidth is greater than or
equal to Bandwidth Threshold
1 and less than Bandwidth Threshold 2, Threshold Metric 1 MUST be
assigned as the Bandwidth Metric on the link during the
Flex-Algorithm SPF calculation.Similarly, when the computed link bandwidth is greater than
or equal to Bandwidth Threshold
2 and less than Bandwidth Threshold 3, Threshold Metric 2 MUST be
assigned as the Bandwidth Metric on the link during the
Flex-Algorithm SPF calculation.In general, when the computed link bandwidth is greater than or
equal to Bandwidth Threshold X AND less than Bandwidth Threshold X+1,
Threshold Metric X MUST be assigned as the Bandwidth Metric on the
link during the Flex-Algorithm SPF calculation.Finally, when the computed link bandwidth is greater than or equal
to Bandwidth Threshold N, then Threshold Metric N MUST be assigned
as the Bandwidth Metric on the link during the Flex-Algorithm SPF
calculation.The IS-IS FADBT sub-TLV MUST NOT appear more than once in an IS-IS FAD
sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV MUST stop
participating in such flex-algorithm.A FAD MUST NOT contain both the FADBT sub-TLV and the FADRB sub-TLV. If both
these sub-TLVs are advertised in the same FAD for a Flexible
Algorithm, the FAD MUST be ignored by the receiver.If a Generic Metric sub-TLV with Bandwidth metric type is advertised
for a link, the Flex-Algorithm calculation MUST use the Bandwidth
Metric advertised on the link, and MUST NOT use the automatically
derived metric for that link.In case of Interface Group Mode, if all the parallel links have
been advertised with the Bandwidth Metric, The individual link Bandwidth
Metric MUST be used. If only some links among the parallel links have the
Bandwidth Metric advertisement, the Bandwidth Metric for such links MUST be
ignored and automatic Metric calculation MUST be used to derive link metric.
This section specifies the rules of deriving the Bandwidth Metric if
and only if the winning FAD for the Flex-Algorithm specifies the
metric-type as "Bandwidth Metric".
1. If the Generic Metric sub-TLV with Bandwidth metric type
is advertised for the link as
described in ,
it MUST be used during the Flex-Algorithm
calculation.2. If the Generic Metric sub-TLV with Bandwidth metric type
is not advertised for the link
and the winning FAD for the Flex-Algorithm does not specify
the automatic bandwidth metric calculation (as defined in
),
the the link is treated as if the Bandwidth Metric is not
available for the link.3. If the Generic Metric sub-TLV with Bandwidth metric type
is not advertised for the link
and the winning FAD for the Flex-Algorithm specifies
the automatic bandwidth metric calculation (as defined in
),
the Bandwidth Metric metric MUST be automatically calculated as per
the procedures defined in .
If the Link Bandwidth is not advertised for a link, the link MUST be
pruned for the Flex-Algorithm calculations.4.In ISIS the Link Bandwidth for Flex-Algorithm purposes is advertised as a
sub-sub-TLV 9 of the Flex-algorithm specific ASLA sub-TLV. It is also possible
to advertise the link bandwidth or Flex-Algorithm, in sub-TLV 9 of
TLV 22/222/23/223/141 [RFC5305], together with the L-Flag set
in the Flex-Algorithm specific ASLA advertisement. In the absence of both
of these advertisements, the bandwidth of the link is not available
for Flex-Algorithm purposes. Two new additional rules are added to the existing rules in the
Flex-Algorithm calculations specified in sec 13 of
.6. Check if any exclude FAEMB rule is part of the Flex-Algorithm
definition. If such exclude rule exists and the link has Maximum Link
Bandwidth advertised, check if the link bandwidth satisfies the
FAEMB rule. If the link does not satisfy the FAEMB rule,
the link MUST be pruned from the Flex-Algorithm computation.7. Check if any exclude FAEMD rule is part of the Flex-Algorithm
definition. If such exclude rule exists and the link has
Min Unidirectional link delay advertised, check if the link delay
satisfies the FAEMD rule. If the link does not satisfy the FAEMD rule,
the link MUST be pruned from the Flex-Algorithm computation. This extension brings no new backward-compatibility issues.
This document defines new FAD constraints in
and
. As described in ,
any node that does not understand sub-TLVs in a FAD TLV, stops participation in the
corresponding Flex-Algorithm. The new extensions can be deployed among the nodes that are
upgraded to understand the new extensions without affecting the nodes that are not upgraded.
This document also defines a new metric advertisement as described in
. As per Sec 13 of ,
the links that do not advertise the metric-type specified by the selected FAD,
the link is pruned from Flex-Algorithm calculations. The new metric-types and the
Flex-Algorithms using new metric-types can be deployed in the network without affecting
existing deployment. This document inherits security considerations from .Operational consideration defined in generally apply to
the extensions defined in this document as well. This document defines metric-type
range for user defined metrics. When user defined metrics are used in an inter-area or
inter-level network, all the domains should assign same meaning to the particular
metric-type.IGP Metric-type Registry is updated to include another column specifying
whether the pariticular metric-type is allowed in the generic-metric sub-TLV or not.
Type: 6(TBD3) Description: IS-IS Exclude Minimum Bandwidth Sub-TLV Reference: This document Type: 7 (TBD4) Description: IS-IS Exclude Maximum Delay Sub-TLV Reference: This document Type: 8 (TBD7) Description: IS-IS Reference Bandwidth Sub-TLV Reference: This document Type: 9(TBD8) Description: IS-IS Threshold Metric Sub-TLV Reference: This document Type:6 (TBD5) Description: OSPF Exclude Minimum Bandwidth Sub-TLV Reference: This document Type: 7(TBD6) Description: OSPF Exclude Maximum Delay Sub-TLV Reference: This document Type: 8(TBD9) Description: OSPF Reference Bandwidth Sub-TLV Reference: This document Type: 9 (TBD10) Description: OSPF Threshold Metric Sub-TLV Reference: This document Type:17 (TBD1) Description: Generic metric Reference: This document Type: 17 (TBD1) Description: Generic metric Reference: This document Type: 25(TBD2) Description: Generic metric Reference: This document Type: 36 (TBD2) Description: Generic metric Reference: This document Type: 34 (TBD2) Description: Generic metric Reference: This document Many thanks to Chris Bowers, Krzysztof Szarcowitz, Julian Lucek,
Ram Santhanakrishnan, Ketan Talaulikar and Acee Lindem
for discussions and inputs.1. Salih K AJuniper Networkssalih@juniper.netThis section lists the entire set of rules to prune links from
Flex-Algorithm topology during Flexible-algorithm calculation.
It includes the original rules defined in Section 13 of
as well as new additions proposed in this document.
For all links in the topology:1. Check if any exclude Administrative Group rule is part of the Flex-Algorithm Definition.
If such exclude rule exists, check if any color that is part of the exclude rule is also set on the link.
If such a color is set, the link MUST be pruned from the computation.2. Check if any exclude SRLG rule is part of the Flex-Algorithm Definition.
If such exclude rule exists, check if the link is part of any SRLG that is a
lso part of the SRLG exclude rule. If the link is part of such SRLG,
the link MUST be pruned from the computation.3. Check if any include-any Administrative Group rule is part
of the Flex-Algorithm Definition. If such include-any rule exists,
check if any color that is part of the include-any rule is also set on the link.
If no such color is set, the link MUST be pruned from the computation.4. Check if any include-all Administrative Group rule is part of the
Flex-Algorithm Definition. If such include-all rule exists, check if all
colors that are part of the include-all rule are also set on the link.
If all such colors are not set on the link, the link MUST be pruned from the
computation.5. If the Flex-Algorithm Definition uses something other than the
IGP metric (Section 5 of ),
and such metric is not advertised for the particular
link in a topology for which the computation is done, such link MUST be pruned
from the computation. A metric of value 0 MUST NOT be assumed in such a case.6. Check if any exclude FAEMB rule is part of the Flex-Algorithm
definition. If such exclude rule exists and the link has Maximum Link
Bandwidth advertised, check if the link bandwidth satisfies the
FAEMB rule. If the link does not satisfy the FAEMB rule,
the link MUST be pruned from the Flex-Algorithm computation.7. Check if any exclude FAEMD rule is part of the Flex-Algorithm
definition. If such exclude rule exists and the link has
Min Unidirectional link delay advertised, check if the link delay
satisfies the FAEMD rule. If the link does not satisfy the FAEMD rule,
the link MUST be pruned from the Flex-Algorithm computation.
&RFC2119;
&RFC5305;
&RFC3630;
&RFC7684;
&RFC9479;
&RFC9492;
&RFC8362;
&RFC9350;
&RFC8570;
&RFC7471;
&RFC5311;
&RFC9346;
&RFC5120;
&RFC5715;