One document matched: draft-ietf-rtgwg-cl-requirement-06.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 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 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 RFC5921 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5921.xml">
<!ENTITY I-D.ietf-l2vpn-vpms-frmwk-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-l2vpn-vpms-frmwk-requirements-04">
<!ENTITY I-D.symmvo-rtgwg-cl-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-symmvo-rtgwg-cl-use-cases-00">
<!ENTITY I-D.so-yong-rtgwg-cl-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-so-yong-rtgwg-cl-framework-05">
]>
<?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" ?>
<!--
Recent changes in response to email.
These email messages were very old but there was a comment in the
XML source that we may have missed chages from them. Two changes
result from these.
Message-ID:
201004110429.o3B4TEmM096179@harbor.orleans.occnc.com
> FR: The precision of latency reporting should be at least 10% of
> the one way latency for latency of 1 ms or more.
Can we just state that it be configurable and that the default be
... [as stated].
[...]
If you are considering keeping the text as is, then change "overload"
to something more meaningful, like maybe "congestion and queueing
delay" and make the last sentence a sentence (grammar doesn't parse).
Message-ID:
793F49BA1FC821409F99F10862A0E4DB06827EA1@FHDP1LUMXCV14.us.one.verizon.com
This email was a followup to the prior email. Most of the places
where changes were suggested could not be found in the current text.
These are more recent emails.
05/06 Curtis Villamizar Re: Ref: Composite link drafts update and reques
Message-Id: <201205061602.q46G2JMW089507@gateway.ipv6.occnc.com>
This was the last in a thread started by Iftekhar Hussain. These
were six action items identified.
#1 Some rewording is needed in Section 3 to clarify MPLS based
component vs physical link component, the latter inclucing the
link layer.
#2 Add a cross reference to CL framework in Section 4.1.
#3 Add cross reference to CL framework near FR#8 and FR#9 regarding
delay metric granularity and inclusion of queuing delay and the
potential impacts on performance, oscillations, and stability.
#4 Add a cross reference to CL Use Cases in Section 4.3 to point
toward the brief description and references that support the
statement "Many techniques have been developed to balance the
distribution of flows across component links that connect the
same pair of nodes" and "...via composite links, other
techniques have been developed."
#5 Briefly explain the "delay discontinuity" that occurs when load
balancing puts traffic on a new path and clarify what is meant
by "minimally disruptive".
#6 It may help in some cases to clarify that something must be
implemented but must, should, or may be configurable and
therefore may be optionally deployed. Doing so may require a
small change to many requirements as in most cases we have only
indicated where something must be implemented.
05/24 Curtis Villamizar change to requirements (was Re: draft-so-yong-rt
Message-Id: <201205241756.q4OHuqIV042399@gateway.ipv6.occnc.com>
05/24 Kireeti Kompella Re: change to requirements (was Re: draft-so-yon
Message-ID: <EE08A25D-CD59-4D8D-B573-19B059654099@juniper.net>
05/24 Kireeti Kompella Re: change to requirements (was Re: draft-so-yon
Message-ID: <E4124166-83DE-4748-8763-47EF4AA5AF17@juniper.net>
05/24 Curtis Villamizar Re: change to requirements (was Re: draft-so-yon
Message-Id: <201205241956.q4OJu4JF046481@gateway.ipv6.occnc.com>
05/24 Kireeti Kompella Re: change to requirements (was Re: draft-so-yon
Message-ID: <DFAB0F00-3794-48A3-99F7-7147CD246538@juniper.net>
05/24 Curtis Villamizar Re: change to requirements (was Re: draft-so-yon
Message-Id: <201205242133.q4OLXPg2049546@gateway.ipv6.occnc.com>
05/24 Iftekhar Hussain RE: change to requirements (was Re: draft-so-yon
Message-ID: <D7D7AB44C06A2440B716F1F1F5E70AE534655FF8@SV-EXDB-PROD1.infinera.com>
06/01 Curtis Villamizar Re: change to requirements (was Re: draft-so-yon
Message-Id: <201206011536.q51Fal7I082882@gateway.ipv6.occnc.com>
The suggested text from these was:
[FR#N] Load balancing MAY be used during sustained low traffic
periods to reduce the number of active component links for
the purpose of power reduction.
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 weight the benefit of power reduction against the
disadvantage of a minimal disruption.
-->
<rfc category="info" ipr="trust200902"
docName="draft-ietf-rtgwg-cl-requirement-06">
<front>
<title abbrev="Composite Link Requirements">
Requirements for MPLS Over a Composite Link</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>
</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." surname="Malis">
<organization>Verizon</organization>
<address>
<postal>
<street>117 West St.</street>
<city>Waltham, MA</city>
<code>02451</code>
</postal>
<phone>+1 781-466-2362</phone>
<email>andrew.g.malis@verizon.com</email>
</address>
</author>
<author
fullname="Lucy Yong" initials="L." surname="Yong">
<organization>Huawei USA</organization>
<address>
<postal>
<street>1700 Alma Dr. Suite 500</street>
<city>Plano, TX</city>
<code>75075</code>
</postal>
<phone>+1 469-229-5387</phone>
<email>lucyyong@huawei.com</email>
</address>
</author>
<date day="7" month="June" year="2012" />
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>RTGWG</workgroup>
<keyword>MPLS</keyword>
<keyword>composite link</keyword>
<keyword>link aggregation</keyword>
<keyword>ECMP</keyword>
<keyword>link bundling</keyword>
<keyword>delay metric</keyword>
<abstract>
<t>
There is often a need to provide large aggregates of bandwidth
that are best provided using parallel links between routers or
MPLS LSR. 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>
Current practice related to multipath is described briefly in
an appendix.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The purpose of this document is to describe why network
operators require certain functions in order to solve certain
business problems (<xref target="assumptions" />). The intent
is to first describe why things need to be done in terms of
functional requirements that are as independent as possible of
protocol specifications (<xref target="FR" />). For certain
functional requirements this document describes a set of
derived protocol requirements (<xref target="DR" />). <xref
target="G.800-Definitions" /> provides a summary of G.800
terminology used to define a composite link.
</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>
</section>
</section>
<section anchor="assumptions" title="Assumptions">
<t>
The services supported include L3VPN <xref
target="RFC4364">RFC 4364</xref>, <xref target="RFC4797">RFC
4797</xref>L2VPN <xref target="RFC4664">RFC 4664</xref> (VPWS,
VPLS (<xref target="RFC4761">RFC 4761</xref>, <xref
target="RFC4762">RFC 4762</xref>) and VPMS <xref
target="I-D.ietf-l2vpn-vpms-frmwk-requirements">VPMS
Framework</xref>), Internet traffic encapsulated by at least
one MPLS label (<xref target="RFC3032">RFC 3032</xref>), and
dynamically signaled MPLS (<xref target="RFC3209">RFC
3209</xref> or <xref target="RFC5036">RFC 5036</xref>) or
MPLS-TP LSPs (<xref target="RFC5921">RFC 5921</xref>) and
pseudowires (<xref target="RFC3985">RFC 3985</xref>). The MPLS
LSPs supporting these services may be point-to-point,
point-to-multipoint, or multipoint-to-multipoint.
</t>
<t>
The locations in a network where these requirements apply are a
Label Edge Router (LER) or a Label Switch Router (LSR) as
defined in <xref target="RFC3031">RFC 3031</xref>.
</t>
<t>
The IP DSCP cannot be used for flow identification since L3VPN
requires Diffserv transparency (see <xref target="RFC4031">RFC
4031 5.5.2</xref>), and in general network operators do not
rely on the DSCP of Internet packets.
</t>
</section>
<section anchor="def" title="Definitions">
<t>
<list hangIndent="4" style="hanging">
<t hangText="ITU-T G.800 Based Composite and Component Link Definitions:">
<vspace blankLines="0" />
<xref target="ITU-T.G.800">Section 6.9.2 of
ITU-T-G.800</xref> defines composite and component links
as summarized in <xref
target="G.800-Definitions"></xref>. The following
definitions for composite and component links are derived
from and intended to be consistent with the cited ITU-T
G.800 terminology.
<list hangIndent="4" style="hanging">
<t hangText="Composite Link:">
A composite link is a logical link composed of a set
of parallel point-to-point component links, where all
links in the set share the same endpoints. A
composite link may itself be a component of another
composite link, but only a strict hierarchy of links
is allowed.
</t>
<t hangText="Component Link:">
A point-to-point physical link (including one or more
link 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 specific NPO. Examples of a
physical link are: any set of link layers over a WDM
wavelength or any supportable combination of Ethernet
PHY, PPP, SONET or OTN over a physical link. Examples
of a logical link are: MPLS LSP, Ethernet VLAN,
MPLS-TP LSP. A set of link layers supported over
pseudowire is a logical link that appears to the
client to be a physical link.
<!-- This is action item #1 -->
</t>
</list>
</t>
<t hangText="Flow:">
A sequence of packets that must be transferred in order on
one component link.
</t>
<t hangText="Flow identification:">
The label stack and other information that uniquely
identifies a flow. Other information in flow
identification may include an IP header, PW control word,
Ethernet MAC address, etc. Note that an LSP may contain
one or more Flows or an 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="Network Performance Objective (NPO):">
Numerical values for performance measures, principally
availability, latency, and delay variation. See <xref
target="I-D.symmvo-rtgwg-cl-use-cases" /> for more details.
</t>
</list>
</t>
</section>
<section anchor="FR" title="Network Operator 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. 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 NPO values.
<xref target="I-D.symmvo-rtgwg-cl-use-cases" /> provides
references and a summary of service types requiring a range
of restoration times.
<list counter="fr" hangIndent="4" style="format FR#%d">
<t>
The solution SHALL provide a means to summarize some
routing advertisements regarding the characteristics of
a composite link such that the routing protocol
converges within the timeframe needed to meet the
network performance objective. A composite link CAN be
announced in conjunction with detailed parameters about
its component links, such as bandwidth and latency. The
composite link SHALL behave as a single IGP adjacency.
</t>
<t>
The solution SHALL ensure that all possible restoration
operations happen within the timeframe needed to meet
the NPO. The solution may need to specify a means for
aggregating signaling to meet this requirement.
</t>
<t>
The solution SHALL provide a mechanism to select a path
for a flow across a network that contains a number of
paths comprised of pairs of nodes connected by composite
links in such a way as to automatically distribute the
load over the network nodes connected by composite links
while meeting all of the other mandatory requirements
stated above. The solution SHOULD work in a manner
similar to that of current networks without any
composite link protocol enhancements when the
characteristics of the individual component links are
advertised.
</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 automatic LSP routing and/or load balancing
solutions MUST not oscillate such that performance
observed by users changes such that an NPO is
violated. 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 composite links.
</t>
</list>
</t>
<t>
Existing scaling techniques used in MPLS networks apply to
MPLS networks which support Composite Links. Scalability
and stability are covered in more detail in <xref
target="I-D.so-yong-rtgwg-cl-framework" />.
<!-- This is action item #2. -->
</t>
</section>
<section anchor="layering"
title="Component Links Provided by Lower Layer
Networks">
<t>
Case 3 as defined in <xref target="ITU-T.G.800" /> involves
a component link supporting an MPLS layer network over
another lower layer network (e.g., circuit switched or
another MPLS network (e.g., MPLS-TP)). The lower layer
network may change the latency (and/or other performance
parameters) seen by the MPLS layer network. Network
Operators have NPOs of which some components are based on
performance parameters. 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>
In order to support network NPOs and provide acceptable
user experience, the solution SHALL specify a protocol
means to allow a lower layer server network to
communicate latency to the higher layer client 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 ms or more.
</t>
<t>
The solution SHALL provide a means to limit the latency
on a per LSP basis between nodes within a network to
meet an NPO target when the path between these nodes
contains one or more pairs of nodes connected via a
composite link. <vspace blankLines="1" /> The NPOs
differ across the services, and some services have
different NPOs for different QoS classes, for example,
one QoS class may have a much larger latency bound than
another. Overload can occur which would violate an NPO
parameter (e.g., loss) and some remedy to handle this
case for a composite link is required.
</t>
<t>
If the total demand offered by traffic flows exceeds the
capacity of the composite link, the solution SHOULD define
a means to cause the LSPs for some traffic flows to move
to some other point in the network that is not
congested. These "preempted LSPs" may not be restored if
there is no uncongested path in the network.
</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 it if used in routing
decisions it can result in routing instability. This
tradeoff is discussed in detail in <xref
target="I-D.so-yong-rtgwg-cl-framework" />.
</t>
<!-- This is action item #3. -->
</section>
<section anchor="multipath-diff"
title="Parallel Component Links with Different Characteristics">
<t>
Corresponding to Case 1 of <xref target="ITU-T.G.800" />, 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. When the path for a
flow can be chosen from a set of candidate nodes connected
via composite links, other techniques have been developed.
Refer to the Appendices in <xref
target="I-D.symmvo-rtgwg-cl-use-cases" /> for a
description of existing techniques and a set of references.
<!-- This is action item #4. -->
</t>
<t>
<list counter="fr" hangIndent="4" style="format FR#%d">
<t>
The solution SHALL measure traffic on a labeled traffic
flow and dynamically select the component link on which
to place this flow in order to balance the load so that
no component link in the composite link between a pair
of nodes is overloaded.
</t>
<t>
When a traffic flow is moved from one component link to
another in the same composite link between a set of
nodes (or sites), it MUST be done so in a minimally
disruptive manner.
</t>
<t>
The solution SHALL provide a means to identify flows
whose rearrangement frequency needs to be bounded by a
configured value.
</t>
<t>
The solution SHALL provide a means that communicates
whether the flows within an LSP can be split across
multiple component links. The solution SHOULD provide a
means to indicate the flow identification field(s) which
can be used along the flow path which can be used to
perform this function.
</t>
<t>
The solution SHALL provide a means to indicate that a
traffic flow shall select a component link with the
minimum latency value.
</t>
<t>
The solution SHALL provide a means to indicate that a
traffic flow shall select a component link with a
maximum acceptable latency value as specified by
protocol.
</t>
<t>
The solution SHALL provide a means to indicate that a
traffic flow shall select a component link with a
maximum acceptable delay variation value as specified by
protocol.
</t>
<t>
The solution SHALL provide a means local to a node that
automatically distributes flows across the component links
in the composite link such that NPOs are met.
</t>
<t>
The solution SHALL provide a means to distribute flows
from a single LSP across multiple component links to
handle at least the case where the traffic carried in an
LSP exceeds that of any component link in the composite
link. As defined in section 3, a flow is a sequence of
packets that must be transferred on one component link.
</t>
<t>
The solution SHOULD support the use case where a
composite link itself is a component link for a higher
order composite link. For example, a composite link
comprised of MPLS-TP bi-directional tunnels viewed as
logical links could then be used as a component link in
yet another composite link that connects MPLS routers.
</t>
<t>
The solution MUST support an optional means for LSP
signaling to bind an LSP to a particular component link
within a composite link. If this option is not
exercised, then an LSP that is bound to a composite link
may be bound to any component link matching all other
signaled requirements, and different directions of a
bidirectional LSP can be bound to different component
links.
</t>
<t>
The solution MUST support a means to indicate that
both directions of co-routed bidirectional LSP MUST be
bound to the same component link.
</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 an NPO.
</t>
<!-- This is action item #5. -->
</section>
</section>
<section anchor="DR" title="Derived Requirements">
<t>
This section takes the next step and derives high-level
requirements on protocol specification from the functional
requirements.
<list counter="dr" hangIndent="4" style="format DR#%d">
<t>
The solution SHOULD attempt to extend existing protocols
wherever possible, developing a new protocol only if this
adds a significant set of capabilities.
</t>
<t>
A solution SHOULD extend LDP capabilities to meet
functional requirements (without using TE methods as
decided in <xref target="RFC3468" />).
</t>
<t>
Coexistence of LDP and RSVP-TE signaled LSPs MUST be
supported on a composite link. Other functional
requirements should be supported as independently of
signaling protocol as possible.
</t>
<t>
When the nodes connected via a composite link are in the
same MPLS network topology, the solution MAY define
extensions to the IGP.
</t>
<t>
When the nodes are connected via a composite link are in
different MPLS network topologies, the solution SHALL NOT
rely on extensions to the IGP.
</t>
<t>
The solution SHOULD support composite link 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: 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 LSPs to be resignaled will cause a period of
unavailability as perceived by users. The resignaling time
of the solution MUST meet the NPO objective for the
duration of unavailability. The resignaling time of the
solution MUST not increase significantly as compared with
current methods.
</t>
</list>
</t>
</section>
<section 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 a composite link and its individual
composite link and support notification of status change.
</t>
<t>
Management Plane MUST be able to activate or de-activate
any component link in a composite link in order to
facilitate operation maintenance tasks. The routers at
each end of a composite link 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 LSP over a
composite link and be able to select a component link for
the LSP.
</t>
<t>
Management Plane MUST be able to trace which component
link a LSP is assigned to and monitor individual component
link and composite link performance.
</t>
<t>
Management Plane MUST be able to verify connectivity over
each individual component link within a composite link.
</t>
<t>
Management Plane SHOULD provide the means for an operator
to initiate an optimization process.
</t>
<t>
Any statement which requires the solution to support some
new functionality through use of the words new
functionality, SHOULD be interpretted 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.
</t>
<!-- This is item #6. -->
</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 WG chairs John
Scuder and Alex Zinin, 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. Infinera continues to
sponsor this work on a consulting basis.
</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>
This document specifies a set of requirements. The
requirements themselves do not pose a security threat. If
these requirements are met using MPLS signaling as commonly
practiced today with authenticated but unencrypted OSPF-TE,
ISIS-TE, and RSVP-TE or LDP, then the requirement to provide
additional information in this communication presents
additional information that could conceivably be gathered in a
man-in-the-middle confidentiality breach. Such an attack
would require a capability to monitor this signaling either
through a provider breach or access to provider physical
transmission infrastructure. A provider breach already poses
a threat of numerous tpes of attacks which are of far more
serious consequence. Encrption of the signaling can prevent
or render more difficult any confidentiality breach that
otherwise might occur by means of access to provider physical
transmission infrastructure.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&RFC3031;
&RFC3032;
&RFC3209;
&RFC3468;
&RFC3985;
&RFC4031;
&RFC4364;
&RFC4664;
&RFC4761;
&RFC4762;
&RFC4797;
&RFC5036;
&RFC5921;
&I-D.ietf-l2vpn-vpms-frmwk-requirements;
&I-D.symmvo-rtgwg-cl-use-cases;
&I-D.so-yong-rtgwg-cl-framework;
<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>
<section anchor="G.800-Definitions"
title="ITU-T G.800 Composite Link Definitions and Terminology">
<t>
<list hangIndent="4" style="hanging">
<t hangText="Composite Link:">
<vspace blankLines="0" />
<xref target="ITU-T.G.800">Section 6.9.2 of
ITU-T-G.800</xref> defines composite link in terms of
three cases, of which the following two are relevant (the
one describing inverse (TDM) multiplexing does not
apply). Note that these case definitions are taken
verbatim from section 6.9, "Layer Relationships".
<list hangIndent="4" style="hanging">
<t hangText="Case 1:">
"Multiple parallel links between the same subnetworks
can be bundled together into a single composite
link. Each component of the composite link is
independent in the sense that each component link is
supported by a separate server layer trail. The
composite link conveys communication information using
different server layer trails thus the sequence of
symbols crossing this link may not be preserved. This
is illustrated in Figure 14."
</t>
<t hangText="Case 3:">
"A link can also be constructed by a concatenation of
component links and configured channel forwarding
relationships. The forwarding relationships must have
a 1:1 correspondence to the link connections that will
be provided by the client link. In this case, it is
not possible to fully infer the status of the link by
observing the server layer trails visible at the ends
of the link. This is illustrated in Figure 16."
</t>
</list>
</t>
<t hangText="Subnetwork:">
A set of one or more nodes (i.e., LER or LSR) and links.
As a special case it can represent a site comprised of
multiple nodes.
</t>
<t hangText="Forwarding Relationship:">
Configured forwarding between ports on a subnetwork. It
may be connectionless (e.g., IP, not considered in this
draft), or connection oriented (e.g., MPLS signaled or
configured).
</t>
<t hangText="Component Link:">
A topolological relationship between subnetworks (i.e., a
connection between nodes), which may be a wavelength,
circuit, virtual circuit or an MPLS LSP.
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:15:56 |