Requirements for Advanced Multipath in MPLS Networks
RFC 7226
|
| Document |
Type |
|
RFC - Informational
(May 2014; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
Submitted to IESG for Publication
|
|
Document shepherd |
|
Alia Atlas
|
|
Shepherd write-up |
|
Show
(last changed 2013-11-25)
|
| IESG |
IESG state |
|
RFC 7226 (Informational)
|
|
Consensus Boilerplate |
|
Yes
|
|
Telechat date |
|
|
|
Responsible AD |
|
Alia Atlas
|
|
Send notices to |
|
(None)
|
| IANA |
IANA review state |
|
Version Changed - Review Needed
|
|
IANA action state |
|
No IANA Actions
|
Internet Engineering Task Force (IETF) C. Villamizar, Ed.
Request for Comments: 7226 OCCNC, LLC
Category: Informational D. McDysan, Ed.
ISSN: 2070-1721 Verizon
S. Ning
Tata Communications
A. Malis
Huawei
L. Yong
Huawei USA
May 2014
Requirements for Advanced Multipath in MPLS Networks
Abstract
This document provides a set of requirements for Advanced Multipath
in MPLS networks.
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.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7226.
Villamizar, et al. Informational [Page 1]
RFC 7226 Advanced Multipath Requirements May 2014
Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functional Requirements . . . . . . . . . . . . . . . . . . . 6
3.1. Availability, Stability, and Transient Response . . . . . 6
3.2. Component Links Provided by Lower-Layer Networks . . . . 7
3.3. Component Links with Different Characteristics . . . . . 8
3.4. Considerations for Bidirectional Client LSP . . . . . . . 9
3.5. Multipath Load-Balancing Dynamics . . . . . . . . . . . . 10
4. General Requirements for Protocol Solutions . . . . . . . . . 12
5. Management Requirements . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Villamizar, et al. Informational [Page 2]
RFC 7226 Advanced Multipath Requirements May 2014
1. Introduction
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 a single packet-processing element.
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 flow as is current practice.
Numerous forms of multipath exist today, including MPLS Link Bundling
Show full document text