Use of Multipath with MPLS and MPLS-TP
draft-ietf-mpls-multipath-use-03

The information below is for an old version of the document
Document Type Active Internet-Draft (mpls WG)
Last updated 2014-01-23 (latest revision 2013-11-13)
Replaces draft-villamizar-mpls-multipath-use
Stream IETF
Intended RFC status Informational
Formats pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Loa Andersson
Shepherd write-up Show (last changed 2013-11-16)
IESG IESG state IESG Evaluation::Revised I-D Needed
Consensus Boilerplate Yes
Telechat date
Needs a YES.
Responsible AD Adrian Farrel
Send notices to mpls-chairs@tools.ietf.org, draft-ietf-mpls-multipath-use@tools.ietf.org
IANA IANA review state IANA OK - No Actions Needed
MPLS                                                  C. Villamizar, Ed.
Internet-Draft                         Outer Cape Cod Network Consulting
Intended status: Informational                         November 13, 2013
Expires: May 17, 2014

                 Use of Multipath with MPLS and MPLS-TP
                    draft-ietf-mpls-multipath-use-03

Abstract

   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.

   Using MPLS Entropy label, MPLS Label Switched Paths (LSPs) can be
   carried over multipath links while also providing a fully MPLS-TP
   compliant server layer for MPLS-TP LSPs.  This document describes the
   means of supporting MPLS as a server layer for MPLS-TP.  The use of
   MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 17, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents

Villamizar                Expires May 17, 2014                  [Page 1]
Internet-Draft         MPLS and MPLS-TP Multipath          November 2013

   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  MPLS as a Server Layer for MPLS-TP  . . . . . . . . . . . . .   4
     3.1.  MPLS-TP Forwarding and Server Layer Requirements  . . . .   4
     3.2.  Methods of Supporting MPLS-TP client LSPs over MPLS . . .   6
   4.  MPLS-TP as a Server Layer for MPLS  . . . . . . . . . . . . .   9
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   6.  Implementation Status . . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Today the requirement to handle large aggregations of traffic, can be
   met 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 [IEEE-802.1AX], link
   bundling [RFC4201], or other aggregation techniques some of which
   could be vendor specific.  Multipath applied to diverse paths rather
   than parallel links includes Equal Cost MultiPath (ECMP) as applied
   to OSPF, IS-IS, or BGP, and equal cost Label Switched Paths (LSPs).
   Some vendors support load split across equal cost MPLS LSPs where the
   load is split proportionally to the reserved bandwidth of the set of
   LSPs.

   RFC 5654 requirement 33 requires the capability to carry a client
   MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer [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 a
   single MPLS-TP LSP due to the inherent MPLS-TP capacity limitation
   imposed by MPLS-TP Operations, Administration, and Maintenance (OAM)
   fate sharing constraints and MPLS-TP LM OAM packet ordering
Show full document text