RTGWG S. Ning
Internet-Draft Tata Communications
Intended status: Informational A.G. Malis
Expires: May 17, 2014 Consultant
D. McDysan
Verizon
L. Yong
Huawei USA
C. Villamizar
Outer Cape Cod Network Consulting
November 13, 2013

Advanced Multipath Use Cases and Design Considerations
draft-ietf-rtgwg-cl-use-cases-05

Abstract

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.

This document provides a set of use cases and design considerations for Advanced Multipath. Existing practices are described. Use cases made possible through Advanced Multipath extensions are described.

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 (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

Advanced Multipath requirements are specified in [I-D.ietf-rtgwg-cl-requirement]. An Advanced Multipath framework is defined in [I-D.ietf-rtgwg-cl-framework].

Multipath techniques have been widely used in IP networks for over two decades. The use of MPLS began more than a decade ago. Multipath has been widely used in IP/MPLS networks for over a decade with very little protocol support dedicated to effective use of multipath.

The state of the art in multipath prior to Advanced Multipath is documented in Appendix B.

Both Ethernet Link Aggregation [IEEE-802.1AX] and MPLS link bundling [RFC4201] have been widely used in today's MPLS networks. Advanced Multipath differs in the following characteristics.

  1. Advanced Multipath allows bundling of non-homogenous links together as a single logical link.
  2. Advanced Multipath provides more information in the TE-LSDB and supports more explicit control over placement of LSP.

2. Assumptions

The supported services are, but not limited to, pseudowire (PW) based services ([RFC3985]), including Virtual Private Network (VPN) services, Internet traffic encapsulated by at least one MPLS label ([RFC3032]), and dynamically signaled MPLS ([RFC3209] or [RFC5036]) or MPLS-TP Label Switched Paths (LSPs) ([RFC5921]).

The MPLS LSPs supporting these services may be point-to-point, point-to-multipoint, or multipoint-to-multipoint. The MPLS LSPs may be signaled using RSVP-TE [RFC3209] or LDP [RFC5036]. With RSVP-TE, extensions to Interior Gateway Protocols (IGPs) may be used, specifically to OSPF-TE [RFC3630] or ISIS-TE [RFC5305].

The locations in a network where these requirements apply are a Label Edge Router (LER) or a Label Switch Router (LSR) as defined in [RFC3031].

The IP DSCP field [RFC2474] [RFC2475] cannot be used for flow identification since L3VPN requires Diffserv transparency (see RFC 4031 5.5.2 [RFC4031]), and in general network operators do not rely on the DSCP of Internet packets.

3. Terminology

Terminology defined in [I-D.ietf-rtgwg-cl-requirement] and [I-D.ietf-mpls-multipath-use] is used in this document.

In addition, the following terms are used:

classic multipath:

Classic multipath refers to the most common current practice in implementation and deployment of multipath (see Appendix B). The most common current practice when applied to MPLS traffic makes use of a hash on the MPLS label stack, and if IPv4 or IPv6 are indicated under the label stack, makes use of the IP source and destination addresses [RFC4385] [RFC4928].
classic link bundling:

Classic link bundling refers to the use of [RFC4201] where the "all ones" component is not used. Where the "all ones" component is used, link bundling behaves as classic multipath does. Classic link bundling selects a single component link to carry all of the traffic for a given LSP.

Among the important distinctions between classic multipath or classic link bundling and Advanced Multipath are:

  1. Classic multipath has no provision to retain packet order within any specific LSP. Classic link bundling retains packet order among any given LSP but as a result does a poor job of splitting load among components and therefore is rarely (if ever) deployed. Advanced Multipath allows per LSP control of load split characteristics.
  2. Classic multipath and classic link bundling do not provide a means to put some LSP on component links with lower delay. Advanced Multipath does.
  3. Classic multipath will provide a load balance for IP and LDP traffic. Classic link bundling will not. Neither classic multipath or classic link bundling will measure IP and LDP traffic and reduce the RSVP-TE advertised "Available Bandwidth" as a result of that measurement. Advanced Multipath better supports RSVP-TE used with significant traffic levels of native IP and native LDP.
  4. Classic link bundling cannot support an LSP that is greater in capacity than any single component link. Classic multipath supports this capability but may reorder traffic on such an LSP. Advanced Multipath can retain order of an LSP that is carried within an LSP that is greater in capacity than any single component link if the contained LSP has such a requirement.

None of these techniques, classic multipath, classic link bundling, or Advanced Multipath, will reorder traffic among IP microflows. None of these techniques will reorder traffic among PW, if a PWE3 Control Word is used [RFC4385].

4. Multipath Foundation Use Cases

A simple multipath composed entirely of physical links is illustrated in Figure 1, where an multipath is configured between LSR1 and LSR2. This multipath has three component links. Individual component links in a multipath may be supported by different transport technologies such as SONET, OTN, Ethernet, etc. Even if the transport technology implementing the component links is identical, the characteristics (e.g., bandwidth, latency) of the component links may differ.

The multipath in Figure 1 may carry LSP traffic flows and control plane packets. Control plane packets may appear as IP packets or may be carried within a generic associated channel (G-Ach) [RFC5586]. A LSP may be established over the link by either RSVP-TE [RFC3209] or LDP [RFC5036] signaling protocols. All component links in a multipath are summarized in the same forwarding adjacency LSP (FA-LSP) routing advertisement [RFC3945]. The multipath is summarized as one TE-Link advertised into the IGP by the multipath end points (the LER if the multipath is MPLS based). This information is used in path computation when a full MPLS control plane is in use.

If Advanced Multipath techniques are used, then the individual component links or groups of component links may optionally be advertised into the IGP as sub-TLV of the multipath FA advertisement to indicate capacity available with various characteristics, such as a delay range.