One document matched: draft-villamizar-mpls-multipath-use-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- xml2rfc is available at http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

  <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC2475 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2475.xml">
  <!ENTITY RFC4201 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4201.xml">
  <!ENTITY RFC5286 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5286.xml">
  <!ENTITY RFC5462 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5462.xml">
  <!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
  <!ENTITY RFC5654 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5654.xml">
  <!ENTITY RFC5714 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5714.xml">
  <!ENTITY RFC5920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5920.xml">

  <!ENTITY I-D.ietf-mpls-entropy-label SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mpls-entropy-label-06">

  <!ENTITY I-D.ietf-mpls-tp-security-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mpls-tp-security-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" ?>

<rfc category="info" ipr="trust200902"
     docName="draft-villamizar-mpls-multipath-use-00">

  <front>
    <title abbrev="MPLS-TP and MPLS Multipath">
      Use of Multipath with MPLS-TP and MPLS</title>

    <author role="editor"
	    fullname="Curtis Villamizar" initials="C." surname="Villamizar">
      <organization>Outer Cape Cod Network Consulting</organization>
      <address>
	<email>curtis@occnc.com</email>
      </address>
    </author>

    <date month="November" year="2012" />

    <area>Routing</area>
    <workgroup>MPLS</workgroup>

    <keyword>MPLS</keyword>
    <keyword>composite link</keyword>
    <keyword>link aggregation</keyword>
    <keyword>ECMP</keyword>
    <keyword>link bundling</keyword>
    <keyword>multipath</keyword>
    <keyword>MPLS-TP</keyword>

    <abstract>
      <t>
	Many MPLS implementations have supported multipath techniques
	and many MPLS deployments have used multipath techniques,
	particularly in very high bandwidth applications, such as
	provider IP/MPLS core networks.  MPLS-TP has strongly
	discouraged the use of multipath techniques.  Some degradation
	of MPLS-TP OAM performance cannot be avoided when operating
	over many types of multipath implementations.
      </t>
      <t>
	Using MPLS Entropy label, MPLS can LSP can be carried over
	multipath links while also providing a fully MPLS-TP compliant
	server layer for MPLS-TP LSP.  This document describes the
	means of supporting MPLS as a server layer for MPLS-TP.  The
	use of MPLS-TP LSP as a server layer for MPLS LSP is also
	discussed.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
	Today the requirement to handle large aggregations of traffic,
	can be handled by a number of techniques which we will
	collectively call multipath.  Multipath applied to parallel
	links between the same set of nodes includes Ethernet Link
	Aggregation <xref target="IEEE-802.1AX" />,
	<xref target="RFC4201">link bundling</xref>, or other
	aggregation techniques some of which may be vendor specific.
	Multipath applied to diverse paths rather than parallel links
	includes Equal Cost MultiPath (ECMP) as applied to OSPF, ISIS,
	or BGP, and equal cost LSP.  Some vendors support load split
	across equal cost MPLS LSP where the load is split
	proportionally to the reserved bandwidth of the set of LSP.
      </t>
      <t>
	RFC 5654 requirement 33 requires the capability to carry a
	client MPLS-TP or MPLS layer over a server MPLS-TP or MPLS
	layer <xref target="RFC5654" />.  This is possible in all
	cases with one exception.  When an MPLS LSP exceeds the
	capacity of any single component link it may be carried by a
	network using multipath techniques, but may not be carried by
	an MPLS-TP LSP due to the inherent MPLS-TP capacity limitation
	imposed by MPLS-TP OAM packet ordering constraints.
      </t>
      <t>
	The term composite link is more general than terms such as
	link aggregation (which is specific to Ethernet) or ECMP
	(which implies equal cost paths within a routing protocol).
	The use of the term composite link here is consistent with the
	broad definition in <xref target="ITU-T.G.800" />.  Multipath
	is very similar to composite link as defined by ITU, but
	specifically excludes inverse multiplexing.
      </t>
    </section>

    <section anchor="sect.def" title="Definitions">
      <t><list style="hanging" hangIndent="4">
	  <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>
		    may be specific paths across a network to a
		    destination node, or
		  </t>
		  <t>
		    may be links or paths to an intermediate node used
		    to reach a common destination.
		  </t>
		</list>
	      </t>
	    </list>
	  </t>
	  <t hangText="Link Bundle"><vspace blankLines="0" />
	    Link bundling is a multipath technique specific to MPLS
	    <xref target="RFC4201" />.  Link bundling supports two
	    modes of operations.  Either an LSP can be placed on one
	    component link of a link bundle, or an LSP can be load
	    split across all members of the bundle.  There is no
	    signaling defined which allows a per LSP preference
	    regarding load split, therefore whether to load split is
	    generally configured per bundle and applied to all LSP
	    across the bundle.
	  </t>
	  <t hangText="Link Aggregation"><vspace blankLines="0" />
	    The term "link aggregation" generally refers
	    to <xref target="IEEE-802.1AX">Ethernet Link
	    Aggregation</xref> as defined by the IEEE.  Ethernet Link
	    Aggregation defines a Link Aggregation Control Protocol
	    (LACP) which coordinates inclusion of LAG members in the
	    LAG.
	  </t>
	  <t hangText="Link Aggregation Group (LAG)">
	    <vspace blankLines="0" /> A group of physical Ethernet
	    interfaces that are treated as a logical link when using
	    Ethernet Link Aggregation is referred to as a Link
	    Aggregation Group (LAG).
	  </t>
	  <t hangText="Equal Cost Multipath (ECMP)">
	    <vspace blankLines="0" /> Equal Cost Multipath (ECMP) is a
	    specific form of multipath in which the costs of the links
	    or paths must be equal in a given routing protocol.  The
	    load may be split equally across all available links (or
	    available paths), or the load may be split proportionally
	    to the capacity of each link (or path).
	  </t>
	  <t hangText="Loop Free Alternate Paths">
	    <vspace blankLines="0" /> "Loop-free alternate paths"
	    (LFA) are defined in <xref target="RFC5714">RFC 5714,
	    Section 5.2</xref> as follows.  "Such a path exists when a
	    direct neighbor of the router adjacent to the failure has
	    a path to the destination that can be guaranteed not to
	    traverse the failure."  Further detail can be found in
	    <xref target="RFC5286" />.  LFA as defined for IPFRR can
	    be used to load balance by relaxing the equal cost
	    criteria of ECMP, though IPFRR defined LFA for use in
	    selecting protection paths.  When used with IP,
	    proportional split is generally not used.  LFA use in load
	    balancing is implemented by some vendors though it may
	    be rare or non-existent in deployments.
	  </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 in
	    <xref target="ITU-T.G.800" />.  The ITU 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 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 multipath.
	  </t>
	  <t hangText="LAG Member"><vspace blankLines="0" />
	    Ethernet Link Aggregation as defined in <xref
	    target="IEEE-802.1AX" /> refers to an individual link in a
	    LAG as a LAG member.  A LAG member is a component link.
	    An Ethernet LAG is a composite link.  IEEE does not use
	    the terms composite link or component link.
	  </t>
	  <t hangText="load split"><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 acheive these
	    objectives than others.
	  </t>
      </list></t>
      <t>
	A small set of requirements are discussed.  These requirements
	make use of keywords such as MUST and SHOULD as described in
	<xref target="RFC2119" />.
      </t>
    </section>

    <section anchor="sect.mpls-server-layer"
	     title="MPLS as a Server Layer for MPLS-TP">
      <t>
	MPLS LSP may be used as a server layer for MPLS-TP LSP as long
	as all MPLS-TP requirements are met, including the requirement
	that packets within an MPLS-TP LSP are not reordered,
	including both payload and OAM packets.
      </t>
      <t>
	Supporting MPLS-TP LSP overa fully MPLS-TP conformant MPLS LSP
	server layer where the MPLS LSP are making use of multipath,
	requires special treatment of the MPLS-TP LSP such that those
	LSP only are not subject to the multipath load slitting.  This
	implies the following brief set of requirements.
	<list counter="mp" hangIndent="4" style="format MP#%d">
	  <t>
	    It MUST be possible to identify MPLS-TP LSP.
	  </t>
	  <t>
	    It SHOULD be possible to completely exclude MPLS-TP LSP
	    from the multipath hash and load split.
	  </t>
	  <t>
	    It SHOULD be possible to insure that an MPLS-TP LSP will
	    not be moved to another component link as a result of a
	    composite link load rebalancing operation.
	  </t>
	  <t>
	    Where an RSVP-TE control plane is used, it MUST be
	    possible for an ingress LSR which is setting up an MPLS-TP
	    or MPLS LSP to determine at CSPF time whether a link or
	    MPLS PSC LSP within the topology can support the MPLS-TP
	    requirements of the LSP.
	  </t>
	</list>
      </t>
      <t>
	There is currently no signaling mechanism defined to support
	requirement MP#1.  In the absense of a signaling extension,
	MPLS-TP can be identified through some form of configuration,
	such as configuration which provides an MPLS-TP compatible
	server layer to all LSP arriving on a specific interface or
	originating from a specific set of ingress LSR.  Alternately
	an MPLS-TP LSP can be created with and Entropy Label Indicator
	(ELI) and entropy label (EL) below the MPLS-TP label
	<xref target="I-D.ietf-mpls-entropy-label" />.
      </t>
      <t>
	Some hardware which exists today can support requirement MP#2.
	Signaling in the absense of MPLS Entropy Label can make use of
	link bundling with a specific component for MPLS-TP LSP and
	link bundling with the all-zeros component for MPLS LSP.  This
	prevents MPLS-TP LSP from being carried within MPLS LSP but
	does allow the co-existance of MPLS-TP and very large MPLS
	LSP.
      </t>
      <t>
	MPLS-TP LSP can be carried as client LSP within an MPLS server
	LSP if an Entropy Label Indicator (ELI) and entropy label (EL)
	is added after the server layer LSP label(s) in the label
	stack, just above the MPLS-TP LSP label entry
	<xref target="I-D.ietf-mpls-entropy-label" />.  This allows
	MPLS-TP LSP to be carried as client LSP within MPLS LSP and
	satisfies requirement MP#2 but requires that MPLS LSR be able
	to identify MPLS-TP LSP (requirement MP#1).
      </t>
      <t>
	MPLS-TP traffic can be protected from an degraded performance
	due to an imperfect load split if the MPLS-TP traffic is given
	queuing priority (using strict priority and policing or
	shaping at ingress or locally or weighted queuing locally).
	This can be accomplished using the Traffic Class field and
	Diffserv treatment of traffic
	<xref target="RFC5462" /><xref target="RFC2475" />.  In the
	event of congestion due to load imbalance, other traffic will
	suffer as long as there is a minority of MPLS-TP traffic.
      </t>
      <t>
	If MPLS-TP LSP are carried within MPLS LSP and ELI and EL are
	used, requirement MP#2 is satisfied, but without a signaling
	extension, requirement MP#3 is not satisfied if there is a
	need to rebalance the load on any composite link carrying the
	MPLS server LSP.  Load rebalance is generally needed only when
	congestion occurs, therefore restricting MPLS-TP to be carried
	only over MPLS LSP that are known to traverse only links which
	are expected to be uncongested can satisfy requirement MP#3.
      </t>
      <t>
	Requirement MP#4 can be supported using administrative
	attributes.  Administrative attributes are defined in
	<xref target="RFC3209" />.  Some configuration is required to
	support this.
      </t>
    </section>
    <section anchor="sect.tp-server-layer"
	     title="MPLS-TP as a Server Layer for MPLS">
      <t>
	Carrying MPLS LSP which are larger than a component link over
	a MPLS-TP server layer requires that the large MPLS client
	layer LSP be accommodated by multiple MPLS-TP server layer
	LSPs.  MPLS multipath can be used in the client layer MPLS.
      </t>
      <t>
	Creating multiple MPLS-TP server layer LSP places a greater
	ILM scaling burden on the LSR.  High bandwidth MPLS cores with
	a smaller amount of nodes have the greatest tendency to
	require LSP in excess of component links, therefore the
	reduction in number of nodes offsets the impact of increasing
	the number of server layer LSP in parallel.  Today, only in
	cases where deployed LSR ILM are small would this be an issue.
      </t>
      <t>
	The most significant disadvantage of MPLS-TP as a Server Layer
	for MPLS is that the use MPLS-TP server layer LSP reduces the
	efficiency of carrying the MPLS client layer.  The service
	which provides by far the largest offered load in provider
	networks is Internet, for which the LSP capacity reservations
	are predictions of expected load.  Many of these MPLS LSP may
	be smaller than component link capacity.  Using MPLS-TP as a
	server layer results in bin packing problems for these smaller
	LSP.  For those LSP that are larger than component link
	capacity, their capacity are not increments of convenient
	capacity increments such as 10Gb/s.  Using MPLS-TP as an
	underlying server layer greatly reduces the ability of the
	client layer MPLS LSP to share capacity.  For example, when
	one MPLS LSP is underutilizing its predicted capacity, the
	fixed allocation of MPLS-TP to component links may not allow
	another LSP to exceed its predicted capacity.  Using MPLS-TP
	as a server layer may result in less efficient use of
	resources may result in a less cost effective network.
      </t>
      <t>
	No additional requirements beyond MPLS-TP as it is now
	currently defined are required to support MPLS-TP as a Server
	Layer for MPLS.  It is therefore viable but has some
	undesirable characteristics discussed above.
      </t>
    </section>

    <!-- Possibly an Acknowledgements or a 'Contributors' section ... -->

    <section anchor="sect.iana" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="sect.security" title="Security Considerations">
      <t>
	This document specifies requirements with discussion of
	framework for solutions using existing MPLS and MPLS-TP
	mechanisms.  The requirements and framework are related to the
	coexistence of MPLS/GMPLS (without MPLS-TP) when used over a
	packet network, MPLS-TP, and multipath.  The combination of
	MPLS, MPLS-TP, and multipath does not introduce any new
	security threats.  The security considerations for MPLS/GMPLS
	and for MPLS-TP are documented in <xref target="RFC5920" />
	and <xref target="I-D.ietf-mpls-tp-security-framework" />.
      </t>
    </section>

  </middle>

  <back>

    <references title="Normative References">

      &RFC2119;

    </references>

    <references title="Informative References">

      &RFC2475;
      &RFC3209;
      &RFC4201;
      &RFC5286;
      &RFC5462;
      &RFC5654;
      &RFC5714;
      &RFC5920;

      &I-D.ietf-mpls-entropy-label;

      &I-D.ietf-mpls-tp-security-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>