One document matched: draft-ietf-rtgwg-cl-requirement-15.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- xml2rfc is available at http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- citation reference entities
from http://xml.resource.org/public/rfc/bibxml -->
<!ENTITY RFC1717 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1717.xml">
<!ENTITY RFC2474 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2474.xml">
<!ENTITY RFC2475 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2475.xml">
<!ENTITY RFC2615 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2615.xml">
<!ENTITY RFC2702 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2702.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2991 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2991.xml">
<!ENTITY RFC2992 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2992.xml">
<!ENTITY RFC3031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml">
<!ENTITY RFC3032 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032.xml">
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC3260 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3260.xml">
<!ENTITY RFC3468 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3468.xml">
<!ENTITY RFC3630 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3630.xml">
<!ENTITY RFC3809 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3809.xml">
<!ENTITY RFC3985 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3985.xml">
<!ENTITY RFC4031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4031.xml">
<!ENTITY RFC4201 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4201.xml">
<!ENTITY RFC4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC4385 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4385.xml">
<!ENTITY RFC4664 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4664.xml">
<!ENTITY RFC4665 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4665.xml">
<!ENTITY RFC4761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4761.xml">
<!ENTITY RFC4762 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4762.xml">
<!ENTITY RFC4797 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4797.xml">
<!ENTITY RFC4928 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4928.xml">
<!ENTITY RFC5036 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5036.xml">
<!ENTITY RFC5254 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5254.xml">
<!ENTITY RFC5305 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml">
<!ENTITY RFC5920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5920.xml">
<!ENTITY RFC5921 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5921.xml">
<!ENTITY RFC6941 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6941.xml">
<!ENTITY I-D.ietf-rtgwg-cl-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-cl-use-cases-01">
<!ENTITY I-D.ietf-rtgwg-cl-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-cl-framework-01">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc comments="yes"?>
<?rfc inline="yes" ?>
<rfc category="info" ipr="trust200902"
docName="draft-ietf-rtgwg-cl-requirement-15">
<front>
<title abbrev="Advanced Multipath Requirements">
Requirements for Advanced Multipath in MPLS Networks</title>
<author role="editor"
fullname="Curtis Villamizar" initials="C." surname="Villamizar">
<organization>OCCNC, LLC</organization>
<address>
<email>curtis@occnc.com</email>
</address>
</author>
<author role="editor"
fullname="Dave McDysan" initials="D." surname="McDysan">
<organization>Verizon</organization>
<address>
<postal>
<street>22001 Loudoun County PKWY</street>
<city>Ashburn, VA</city>
<code>20147</code>
<country>USA</country>
</postal>
<email>dave.mcdysan@verizon.com</email>
</address>
</author>
<author
fullname="So Ning" initials="S." surname="Ning">
<organization>Tata Communications</organization>
<address>
<email>ning.so@tatacommunications.com</email>
</address>
</author>
<author
fullname="Andrew Malis" initials="A.G." surname="Malis">
<organization>Consultant</organization>
<address>
<email>agmalis@gmail.com</email>
</address>
</author>
<author
fullname="Lucy Yong" initials="L." surname="Yong">
<organization>Huawei USA</organization>
<address>
<postal>
<street>5340 Legacy Dr.</street>
<city>Plano, TX</city>
<code>75025</code>
<country>USA</country>
</postal>
<phone>+1 469-277-5837</phone>
<email>lucy.yong@huawei.com</email>
</address>
</author>
<date year="2014" />
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>RTGWG</workgroup>
<keyword>MPLS</keyword>
<keyword>Advanced Multipath</keyword>
<keyword>composite link</keyword>
<keyword>link aggregation</keyword>
<keyword>ECMP</keyword>
<keyword>link bundling</keyword>
<keyword>delay metric</keyword>
<abstract>
<t>
This document provides a set of requirements for Advanced
Multipath in MPLS Networks.
</t>
<t>
Advanced Multipath is a formalization of multipath techniques
currently in use in IP and MPLS networks and a set of
extensions to existing multipath techniques.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
There is often a need to provide large aggregates of bandwidth
that are best provided using parallel links between routers or
carrying traffic over multiple MPLS Label Switched Paths
(LSPs). In core networks there is often no alternative since
the aggregate capacities of core networks today far exceed the
capacity of a single physical link or single packet processing
element.
</t>
<t>
The presence of parallel links, with each link potentially
comprised of multiple layers has resulted in additional
requirements. Certain services may benefit from being
restricted to a subset of the component links or a specific
component link, where component link characteristics, such as
latency, differ. Certain services require that an LSP be
treated as atomic and avoid reordering. Other services will
continue to require only that reordering not occur within a
microflow as is current practice.
</t>
<t><!-- moved due to RtgDir review -->
Numerous forms of multipath exist today including
MPLS Link Bundling
<xref target="RFC4201" />,
Ethernet Link Aggregation
<xref target="IEEE-802.1AX" />,
and various forms of Equal Cost Multipath (ECMP) such as for
OSPF ECMP, IS-IS ECMP, and BGP ECMP.
Refer to the Appendices in
<xref target="I-D.ietf-rtgwg-cl-use-cases" />
for a description of existing techniques and a set of
references.
</t><!-- end moved paragraph -->
<t>
The purpose of this document is to clearly enumerate a set of
requirements related to the protocols and mechanisms that
provide MPLS based Advanced Multipath. The intent is to first
provide a set of functional requirements that are as
independent as possible of protocol specifications in
<xref target="FR" />. A set of general protocol requirements
are defined in <xref target="GR" />. A set of network
management requirements are defined in <xref target="MR" />.
</t>
<section title="Requirements Language">
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
</t>
<t>
Any statement which requires the solution to support some
new functionality through use of <xref target="RFC2119" />
keywords should be interpreted as follows. The
implementation either MUST or SHOULD support the new
functionality depending on the use of either MUST or SHOULD
in the requirements statement. The implementation SHOULD in
most or all cases allow any new functionality to be
individually enabled or disabled through configuration. A
service provider or other deployment MAY enable or
disable any feature in their network, subject to
implementation limitations on sets of features which can be
disabled.
</t>
</section>
</section>
<section anchor="def" title="Definitions">
<t>
<list hangIndent="4" style="hanging">
<t hangText="Multipath">
<vspace blankLines="0" />
The term multipath includes all techniques in which
<list style="numbers">
<t>
Traffic can take more than one path from one node to a
destination.
</t>
<t>
Individual packets take one path only. Packets are
not subdivided and reassembled at the receiving end.
</t>
<t>
Packets are not resequenced at the receiving end.
</t>
<t>
The paths may be:
<list style="letters">
<t>
parallel links between two nodes, or
</t>
<t>
specific paths across a network to a
destination node, or
</t>
<t>
links or paths to an intermediate node used
to reach a common destination.
</t>
</list>
</t>
</list>
The paths need not have equal capacity. The paths may or
may not have equal cost in a routing protocol.
</t>
<t hangText="Advanced Multipath">
<vspace blankLines="0" />
Advanced Multipath is a formalization of multipath
techniques that meets the requirements defined in this
document. A key capability of Advanced Multipath is the
support of non-homogeneous component links.
</t>
<t hangText="Advanced Multipath Group (AMG)">
<vspace blankLines="0" />
An Advanced Multipath Group (AMG) is a collection of
component links where Advanced Multipath techniques are
applied.
</t>
<t hangText="Composite Link">
<vspace blankLines="0" />
The term Composite Link had been a registered trademark of
Avici Systems, but was abandoned in 2007. The term
composite link is now defined by the ITU-T in
<xref target="ITU-T.G.800" />. The ITU-T definition
includes multipath as defined here, plus inverse
multiplexing which is explicitly excluded from the
definition of multipath.
</t>
<t hangText="Inverse Multiplexing">
<vspace blankLines="0" />
Inverse multiplexing either transmits whole packets and
resequences the packets at the receiving end or subdivides
packets and reassembles the packets at the receiving end.
Inverse multiplexing requires that all packets be handled
by a common egress packet processing element and is
therefore not useful for very high bandwidth applications.
</t>
<t hangText="Component Link">
<vspace blankLines="0" />
The ITU-T definition of composite link in
<xref target="ITU-T.G.800" /> and the IETF definition of
link bundling in <xref target="RFC4201" /> both refer to
an individual link in the composite link or link bundle as
a component link. The term component link is applicable
to all forms of multipath. The IEEE uses the term member
rather than component link in Ethernet Link Aggregation
<xref target="IEEE-802.1AX" />.
</t>
<t hangText="Client Layer">
<vspace blankLines="0" />
A client layer is the one immediately above a server layer.
</t>
<t hangText="Server Layer">
<vspace blankLines="0" />
A server layer is the latey immediately below a client layer.
</t>
<t hangText="Higher Layers">
<vspace blankLines="0" />
Relative to a particular layer, a client layer and any
layer above that is considered a higher layer. Upper
layer is synonymous with higher layer.
</t>
<t hangText="Lower Layers">
<vspace blankLines="0" />
Relative to a particular layer, a server layer and any
layer below that is considered a lower layer.
</t>
<t hangText="Client LSP">
<vspace blankLines="0" />
A client LSP is an LSP which has been set up over one or
more lower layers. In the context of this discussion, one
type of client LSP is a LSP which has been set up over an
AMG.
</t>
<t hangText="Flow">
<vspace blankLines="0" />
A sequence of packets that should be transferred in order on
one component link of a multipath.
</t>
<t hangText="Flow identification">
<vspace blankLines="0" />
The label stack and other information that uniquely
identifies a flow. Other information in flow
identification may include an IP header, pseudowire (PW)
control word, Ethernet MAC address, etc. Note that a
client LSP may contain one or more Flows or a client LSP
may be equivalent to a Flow. Flow identification is used
to locally select a component link, or a path through the
network toward the destination.
</t>
<t hangText="Load Balance">
<vspace blankLines="0" />
Load split, load balance, or load distribution refers to
subdividing traffic over a set of component links such
that load is fairly evenly distributed over the set of
component links and certain packet ordering requirements
are met. Some existing techniques better achieve these
objectives than others.
</t>
<t hangText="Performance Objective">
<vspace blankLines="0" />
Numerical values for performance measures, principally
availability, latency, and delay variation. Performance
objectives may be related to Service Level Agreements
(SLA) as defined in RFC2475 or may be strictly internal.
Performance objectives may span links, edge-to-edge, or
end-to-end. Performance objectives may span one provider
or may span multiple providers.
</t>
</list>
</t>
<t>
A Component Link may be a point-to-point physical link (where
a "physical link" includes one or more link layer plus a
physical layer) or a logical link that preserves ordering in
the steady state. A component link may have transient out of
order events, but such events must not exceed the network's
Performance Objectives. For example, a component link may be
comprised of any supportable combination of link layers over a
physical layer or over logical sub-layers, including those
providing physical layer emulation, or over MPLS server layer
LSP.
</t>
<t>
The ingress and egress of a multipath may be midpoint LSRs
with respect to a given client LSP. A midpoint LSR does not
participate in the signaling of any clients of the client LSP.
Therefore, in general, multipath endpoints cannot determine
requirements of clients of a client LSP through participation
in the signaling of the clients of the client LSP.
</t>
<t>
This document makes no statement on whether Advanced Multipath
is itself a layer or whether an instance of AMG is itself a
layer. This is to avoid engaging in long and pointless
discussions about what consistitutes a proper layer.
<!-- alternste:
This document takes no position on whether an AMG constitutes
a distinct layer or a distinct sub-layer or neither in the
data plane or control plane. An AMG will need to be a
distinct entity in the management plane but no position is
taken as to whether an AMG constitues some form of distinct
layer even in the management plane.
-->
</t>
<t>
The term Advanced Multipath is intended to be used within the
context of this document and the related documents,
<xref target="I-D.ietf-rtgwg-cl-use-cases" />
and
<xref target="I-D.ietf-rtgwg-cl-framework" />
and any other related document. Other advanced multipath
techniques may in the future arise. If the capabilities
defined in this document become commonplace, they would no
longer be considered "advanced". Use of the term "advanced
multipath" outside this document, if referring to the term as
defined here, should indicate Advanced Multipath as defined by
this document, citing the current document name. If using
another definition of "advanced multipath", documents may
optionally clarify that they are not using the term "advanced
multipath" as defined by this document if clarification is
deemed helpful.
</t>
</section>
<section anchor="FR" title="Functional Requirements">
<t>
The Functional Requirements in this section are grouped in
subsections starting with the highest priority.
</t>
<section anchor="it-works"
title="Availability, Stability and Transient Response">
<t>
Limiting the period of unavailability in response to
failures or transient events is extremely important as well
as maintaining stability.
</t>
<t>
<list counter="fr" hangIndent="4" style="format FR#%d">
<t><!-- promoted to requirement due to RtgDir review -->
The transient period between some service disrupting
event and the convergence of the routing and/or
signaling protocols MUST occur within a time frame
specified by Performance Objective values.
</t><!-- end promoted requirement -->
<t>
An AMG MAY be announced in conjunction with
detailed parameters about its component links, such as
bandwidth and latency. The AMG SHALL behave
as a single IGP adjacency.
</t>
<t>
The solution SHALL provide a means to summarize some
routing advertisements regarding the characteristics of
an AMG such that the updated protocol
mechanisms maintain convergence times within the
timeframe needed to meet or not significantly exceed
existing Performance Objective for convergence on the
same network or convergence on a network with a similar
topology.
</t>
<t>
The solution SHALL ensure that restoration operations
happen within the timeframe needed to meet existing
Performance Objective for restoration time on the same
network or restoration time on a network with a similar
topology.
</t>
<t>
The solution shall provide a mechanism to select a set
of paths for an LSP across a network in such a way that
flows within the LSP are distributed across the set of
paths while meeting all of the other requirements stated
above. The solution SHOULD work in a manner similar to
existing multipath techniques except as necessary to
accommodate Advanced Multipath requirements.
</t>
<t>
If extensions to existing protocols are specified and/or
new protocols are defined, then the solution SHOULD
provide a means for a network operator to migrate an
existing deployment in a minimally disruptive manner.
</t>
<t>
Any load balancing solutions MUST NOT oscillate. Some
change in path MAY occur. The solution MUST ensure that
path stability and traffic reordering continue to meet
Performance Objective on the same network or on a
network with a similar topology. Since oscillation may
cause reordering, there MUST be means to control the
frequency of changing the component link over which a
flow is placed.
</t>
<t>
Management and diagnostic protocols MUST be able to
operate over AMGs.
</t>
</list>
</t>
<t>
Existing scaling techniques used in MPLS networks apply to
MPLS networks which support Advanced Multipath. Scalability
and stability are covered in more detail in
<xref target="I-D.ietf-rtgwg-cl-framework" />.
</t>
</section>
<section anchor="layering"
title="Component Links Provided by Lower Layer Networks">
<t>
A component link may be supported by a lower layer network.
For example, the lower layer may be a circuit switched
network or another MPLS network (e.g., MPLS-TP)). The lower
layer network may change the latency (and/or other
performance parameters) seen by the client layer.
Currently, there is no protocol for the lower layer network
to inform the higher layer network of a change in a
performance parameter. Communication of the latency
performance parameter is a very important requirement.
Communication of other performance parameters (e.g., delay
variation) is desirable.
<list counter="fr" hangIndent="4" style="format FR#%d">
<t>
The solution SHALL specify a protocol means to allow a
server layer network to communicate latency to the
client layer network.
</t>
<t>
The precision of latency reporting SHOULD be
configurable. A reasonable default SHOULD be provided.
Implementations SHOULD support precision of at least 10%
of the one way latencies for latency of 1 msec or more.
</t>
</list>
</t>
<t>
The intent is to measure the predominant latency in
uncongested service provider networks, where geographic
delay dominates and is on the order of milliseconds or more.
The argument for including queuing delay is that it reflects
the delay experienced by applications. The argument against
including queuing delay is that if used in routing decisions
it can result in routing instability. This tradeoff is
discussed in detail in <xref
target="I-D.ietf-rtgwg-cl-framework" />.
</t>
</section>
<section anchor="multipath-diff"
title="Component Links with Different Characteristics">
<t>
As one means to provide high availability, network operators
deploy a topology in the MPLS network using lower layer
networks that have a certain degree of diversity at the
lower layer(s). Many techniques have been developed to
balance the distribution of flows across component links
that connect the same pair of nodes or ultimately lead to a
common destination.
</t>
<t>
<list counter="fr" hangIndent="4" style="format FR#%d">
<t><!-- new requirement from RtgDir review -->
In requirements that follow in this document the word
"indicate" is used where information may be provided by
either the combination of link state IGP advertisement
and MPLS LSP signaling or via management plane
protocols. In later documents providing framework and
protocol definitions both signaling and management plane
mechanisms MUST be defined.
</t><!-- end new requirement -->
<t>
The solution SHALL provide a means for the client layer
to indicate a requirement that a client LSP will
traverse a component link with the minimum latency
value. This will provide a means by which minimum
latency Performance Objectives of flows within the
client LSP can be supported.
</t>
<t>
The solution SHALL provide a means for the client layer
to indicate a requirement that a client LSP will
traverse a component link with a maximum acceptable
latency value as specified by protocol. This will
provide a means by which bounded latency Performance
Objectives of flows within the client LSP can be
supported.
</t>
<t>
The solution SHALL provide a means for the client layer
to indicate a requirement that a client LSP will
traverse a component link with a maximum acceptable
delay variation value as specified by protocol.
</t>
</list>
</t>
<t>
The above set of requirements apply to component links with
different characteristics regardless as to whether those
component links are provided by parallel physical links
between nodes or provided by sets of paths across a network
provided by server layer LSP.
</t>
<t>
Allowing multipath to contain component links with different
characteristics can improve the overall load balance and can
be accomplished while still accommodating the more strict
requirements of a subset of client LSP.
</t>
</section>
<section anchor="multipath-bidir"
title="Considerations for Bidirectional Client LSP">
<t>
Some client LSP MAY require a path bound to a specific set
of component links. This case is most likely to occur in
bidirectional client LSP where time synchronization
protocols such as Precision Time Protocol (PTP) or Network
Time Protocol (NTP) are carried, or in any other case where
symmetric delay is highly desirable. There may be other
uses of this capability.
</t>
<t>
Other client LSP may only require that the LSP path serve
the same set of nodes in both directions. This is necessary
if protocols are carried which make use of the reverse
direction of the LSP as a back channel in cases such OAM
protocols using IPv4 Time to Live (TTL) or IPv4 Hop Limit to
monitor or diagnose the underlying path. There may be other
uses of this capability.
</t>
<t>
<list counter="fr" hangIndent="4" style="format FR#%d">
<t>
The solution SHALL provide a means for the client layer
to indicate a requirement that a client LSP be bound to
a particular component link within an AMG. If this
option is not exercised, then a client LSP that is
carried over an AMG may be bound to any component link
or set of component links matching all other signaled
requirements, and different directions of a
bidirectional client LSP can be bound to different
component links.
</t>
<t>
The solution MUST support a means for the client layer
to indicate a requirement that for a specific co-routed
bidirectional client LSP both directions of the
co-routed bidirectional client LSP MUST be bound to the
same set of nodes.
</t>
<t>
A client LSP which is bound to a specific component link
SHOULD NOT exceed the capacity of a single component
link. This is inherent in the assumption that a network
SHOULD NOT operate in a congested state if congestion is
avoidable.
</t>
</list>
</t>
<t>
For some large bidirectional client LSP it may not be
necessary (or possible due to the client LSP capacity) to
bind the LSP to a common set of component links but may be
necessary or desirable to constrain the path taken by the
LSP to the same set of nodes in both directions. Without
an entirely new and highly dynamic protocol, it is not
feasible to constrain such an bidirectional client LSP to
take multiple paths and coordinate load balance on each side
to keep both directions of flows within such an LSP on
common paths.
</t>
</section>
<section anchor="multipath-dyn"
title="Multipath Load Balancing Dynamics">
<t>
Multipath load balancing attempts to keep traffic levels on
all component links below congestion levels if possible and
preferably well balanced. Load balancing is minimally
disruptive (see discussion below this section's list of
requirements). The sensitivity to these minimal disruptions
of traffic flows within specific client LSP needs to be
considered.
</t>
<t>
<list counter="fr" hangIndent="4" style="format FR#%d">
<t>
The solution SHALL provide a means for the client layer
to indicate a requirement that a specific client LSP
MUST NOT be split across multiple component links.
</t>
<t>
The solution SHALL provide a means local to a node that
automatically distributes flows across the component
links in the AMG such that Performance
Objectives are met as described in prior requirements in
<xref target="multipath-diff" />.
</t>
<t>
The solution SHALL measure traffic flows or groups of
traffic flows and dynamically select the component link
on which to place this traffic in order to balance the
load so that no component link in the AMG between a pair
of nodes is overloaded.
</t>
<t>
When a traffic flow is moved from one component link to
another in the same AMG between a set of nodes, it MUST
be done so in a minimally disruptive manner.
</t>
<t>
Load balancing MAY be used during sustained low traffic
periods to reduce the number of active component links
for the purpose of power reduction.
</t>
<t>
The solution SHALL provide a means for the client layer
to indicate a requirement that a specific client LSP
contains traffic whose frequency of component link
change due to load balancing needs to be bounded by a
specific value. The solution MUST provide a means to
bound the frequency of component link change due to load
balancing for subsets of traffic flow on AMGs.
</t>
<t>
The solution SHALL provide a means to distribute traffic
flows from a single client LSP across multiple component
links to handle at least the case where the traffic
carried in an client LSP exceeds that of any component
link in the AMG.
</t>
<t>
The solution SHOULD support the use case where an
AMG itself is a component link for a
higher order AMG. For example, an
AMG comprised of MPLS-TP bi-directional
tunnels viewed as logical links could then be used as a
component link in yet another AMG that
connects MPLS routers.
</t>
<t>
If the total demand offered by traffic flows exceeds the
capacity of the AMG, the solution SHOULD
define a means to cause some client LSP to move to an
alternate set of paths that are not congested. These
"preempted LSP" may not be restored if there is no
uncongested path in the network.
</t>
</list>
</t>
<t>
A minimally disruptive change implies that as little
disruption as is practical occurs. Such a change can be
achieved with zero packet loss. A delay discontinuity may
occur, which is considered to be a minimally disruptive
event for most services if this type of event is
sufficiently rare. A delay discontinuity is an example of a
minimally disruptive behavior corresponding to current
techniques.
</t>
<t>
A delay discontinuity is an isolated event which may greatly
exceed the normal delay variation (jitter). A delay
discontinuity has the following effect. When a flow is
moved from a current link to a target link with lower
latency, reordering can occur. When a flow is moved from a
current link to a target link with a higher latency, a time
gap can occur. Some flows (e.g., timing distribution, PW
circuit emulation) are quite sensitive to these effects. A
delay discontinuity can also cause a jitter buffer underrun
or overrun affecting user experience in real time voice
services (causing an audible click). These sensitivities
may be specified in a Performance Objective.
</t>
<t>
As with any load balancing change, a change initiated for
the purpose of power reduction may be minimally disruptive.
Typically the disruption is limited to a change in delay
characteristics and the potential for a very brief period
with traffic reordering. The network operator when
configuring a network for power reduction should weigh the
benefit of power reduction against the disadvantage of a
minimal disruption.
</t>
</section>
</section>
<section anchor="GR" title="General Requirements for Protocol Solutions">
<t>
This section defines requirements for protocol specification
used to meet the functional requirements specified in
<xref target="FR" />.
</t>
<t>
<list counter="gr" hangIndent="4" style="format GR#%d">
<t>
The solution SHOULD extend existing protocols wherever
possible, developing a new protocol only where doing so
adds a significant set of capabilities.
</t>
<t>
A solution SHOULD extend LDP capabilities to meet
functional requirements. This MUST be accomplished
without defining LDP Traffic Engineering (TE) methods as
decided in <xref target="RFC3468" />).
</t>
<t>
Coexistence of LDP and RSVP-TE signaled LSPs MUST be
supported on an AMG.
Function requirements SHOULD, where possible, be
accommodated in a manner that supports LDP signaled LSP,
RSVP signaled LSP, and LSP set up using management plane
mechanisms.
</t>
<t>
When the nodes connected via an AMG are in the
same routing domain, the solution MAY define
extensions to the IGP.
</t>
<t>
When the nodes are connected via an AMG are in
different MPLS network topologies, the solution SHALL NOT
rely on extensions to the IGP.
</t>
<t>
The solution SHOULD support AMG IGP
advertisement that results in convergence time better than
that of advertising the individual component links. The
solution SHALL be designed so that it represents the range
of capabilities of the individual component links such
that functional requirements are met, and also minimizes
the frequency of advertisement updates which may cause IGP
convergence to occur.
<vspace blankLines="1" /> Examples of advertisement update
triggering events to be considered include: client LSP
establishment/release, changes in component link
characteristics (e.g., latency, up/down state), and/or
bandwidth utilization.
</t>
<t>
When a worst case failure scenario occurs, the number of
RSVP-TE client LSPs to be resignaled will cause a period of
unavailability as perceived by users. The resignaling time
of the solution MUST support protocol mechanisms meeting
existing provider Performance Objective for the duration
of unavailability without significantly relaxing those
existing Performance Objectives for the same network or
for networks with similar topology. For example, the
processing load due to IGP readvertisement MUST NOT
increase significantly and the resignaling time of the
solution MUST NOT increase significantly as compared with
current methods.
</t>
</list>
</t>
</section>
<section anchor="MR" title="Management Requirements">
<t>
<list counter="mr" hangIndent="4" style="format MR#%d">
<t>
Management Plane MUST support polling of the status and
configuration of an AMG and its individual component links
and support notification of status change.
</t>
<t>
Management Plane MUST be able to activate or de-activate
any component link in an AMG in order to
facilitate operation maintenance tasks. The routers at
each end of an AMG MUST redistribute traffic to
move traffic from a de-activated link to other component
links based on the traffic flow TE criteria.
</t>
<t>
Management Plane MUST be able to configure a client LSP
over an AMG and be able to select a
component link for the client LSP.
</t>
<t>
Management Plane MUST be able to trace which component
link a client LSP is assigned to and monitor individual
component link and AMG performance.
</t>
<t>
Management Plane MUST be able to verify connectivity over
each individual component link within an AMG.
</t>
<t>
Component link fault notification MUST be sent to the
management plane.
</t>
<t>
AMG fault notification MUST be sent to the
management plane and MUST be distributed via link state
message in the IGP.
</t>
<t>
Management Plane SHOULD provide the means for an operator
to initiate an optimization process.
</t>
<t>
An operator initiated optimization MUST be performed in a
minimally disruptive manner as described in
<xref target="multipath-dyn" />.
</t>
</list>
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Frederic Jounay of France Telecom and Yuji Kamite of NTT
Communications Corporation co-authored a version of this
document.
</t>
<t>
A rewrite of this document occurred after the IETF77 meeting.
Dimitri Papadimitriou, Lou Berger, Tony Li, the former WG
chairs John Scuder and Alex Zinin, the current WG chair Alia
Atlas, and others provided valuable guidance prior to and at
the IETF77 RTGWG meeting.
</t>
<t>
Tony Li and John Drake have made numerous valuable comments on
the RTGWG mailing list that are reflected in versions
following the IETF77 meeting.
</t>
<t>
Iftekhar Hussain and Kireeti Kompella made comments on the
RTGWG mailing list after IETF82 that identified a new
requirement. Iftekhar Hussain made numerous valuable comments
on the RTGWG mailing list that resulted in improvements to
document clarity.
</t>
<t>
In the interest of full disclosure of affiliation and in the
interest of acknowledging sponsorship, past affiliations of
authors are noted. Much of the work done by Ning So occurred
while Ning was at Verizon. Much of the work done by Curtis
Villamizar occurred while at Infinera. Much of the work done
by Andy Malis occurred while Andy was at Verizon.
</t>
<t>
Tom Yu and Francis Dupont provided the SecDir and GenArt
reviews respectively. Both reviews provided useful comments.
The current wording of the security section is based on
suggested wording from Tom Yu. Lou Berger provided the RtgDir
review which resulted in the document being renamed and
substantial clarification of terminology and document wording,
particularly in the Abstract, Introduction, and Definitions
sections.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
The security considerations for MPLS/GMPLS and for MPLS-TP are
documented in <xref target="RFC5920" /> and <xref
target="RFC6941" />. This document does not impact the
security of MPLS, GMPLS, or MPLS-TP.
</t>
<t>
The additional information that this document requires does
not provide significant additional value to an attacker beyond
the information already typically available from attacking a
routing or signaling protocol. If the requirements of this
document are met by extending an existing routing or signaling
protocol, the security considerations of the protocol being
extended apply. If the requirements of this document are met
by specifying a new protocol, the security considerations of
that new protocol should include an evaluation of what level
of protection is required by the additional information
specified in this document, such as data origin
authentication.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&RFC3468;
&RFC4201;
&RFC5920;
&RFC6941;
&I-D.ietf-rtgwg-cl-use-cases;
&I-D.ietf-rtgwg-cl-framework;
<reference anchor="IEEE-802.1AX"
target="http://standards.ieee.org/getieee802/download/802.1AX-2008.pdf">
<front>
<title>IEEE Std 802.1AX-2008 IEEE Standard for
Local and Metropolitan Area Networks - Link Aggregation</title>
<author>
<organization>IEEE Standards Association</organization>
</author>
<date year="2006" />
</front>
</reference>
<reference anchor="ITU-T.G.800"
target="http://www.itu.int/rec/T-REC-G/recommendation.asp?parent=T-REC-G.800">
<front>
<title>Unified functional architecture of transport
networks</title>
<author>
<organization>ITU-T</organization>
</author>
<date year="2007" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:14:58 |