One document matched: draft-villamizar-mpls-tp-multipath-te-extn-01.txt
Differences from draft-villamizar-mpls-tp-multipath-te-extn-00.txt
MPLS C. Villamizar, Ed.
Internet-Draft Outer Cape Cod Network
Intended status: Standards Track Consulting
Expires: August 30, 2012 February 27, 2012
Multipath Extensions for MPLS Traffic Engineering
draft-villamizar-mpls-tp-multipath-te-extn-01
Abstract
Extensions to OSPF-TE, ISIS-TE, and RSVP-TE are defined in support of
carrying LSP with strict packet ordering requirements over multipath
and and carrying LSP with strict packet ordering requirements within
LSP without violating requirements to maintain packet ordering. LSP
with strict packet ordering requirements include MPLS-TP LSP.
OSPF-TE and ISIS-TE extensions defined here indicate node and link
capability regarding support for ordered aggregates of traffic,
multipath traffic distribution, and abilities to support multipath
load distribution differently per LSP.
RSVP-TE extensions either identifies an LSP as requiring strict
packet order, or identifies an LSP as carrying one or more LSP that
requires strict packet order at a given depth in the label stack, or
identifies an LSP as having no restrictions on packet ordering except
the restriction to avoid reordering microflows. In addition an
extension indicates whether the first nibble of payload will reliably
indicate whether payload is IPv4, IPv6, or other type of payload,
most notably pseudowire using a pseudowire control word.
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 August 30, 2012.
Villamizar Expires August 30, 2012 [Page 1]
Internet-Draft MPLS TE Multipath February 2012
Copyright Notice
Copyright (c) 2012 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.
Villamizar Expires August 30, 2012 [Page 2]
Internet-Draft MPLS TE Multipath February 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Architecture Summary . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5
2.1. Multipath Node Capability sub-TLV . . . . . . . . . . . . 6
2.2. Multipath Link Capability TLV . . . . . . . . . . . . . . 9
2.3. Contained Ordered Aggregate Attributes TLV . . . . . . . . 9
2.4. LSP Multipath Attributes TLV . . . . . . . . . . . . . . . 11
3. Multipath Extension Protocol Mechanisms . . . . . . . . . . . 12
3.1. OSPF-TE and ISIS-TE Advertisement . . . . . . . . . . . . 12
3.1.1. Node Capability Advertisement . . . . . . . . . . . . 12
3.1.2. Link Capability Advertisement . . . . . . . . . . . . 13
3.1.3. Setting Max Depth and IP Depth . . . . . . . . . . . . 13
3.1.4. Hierarchical LSP Link Advertisement . . . . . . . . . 13
3.2. RSVP-TE LSP Attributes . . . . . . . . . . . . . . . . . . 14
3.2.1. LSP Attributes for Ordered Aggregates . . . . . . . . 14
3.2.2. LSP Attributes for Ordered Aggregates . . . . . . . . 15
3.2.3. Attributes for LSP without Packet Ordering . . . . . . 15
3.3. Path Computation Constraints . . . . . . . . . . . . . . . 16
3.3.1. Link Multipath Capabilities and Path Computation . . . 16
3.3.1.1. Path Computation with Ordering Constraints . . . . 17
3.3.1.2. Path Computation with No Ordering Constraint . . . 17
3.3.1.3. Path Computation for MPLS containing MPLS-TP . . . 17
3.3.2. Link IP Capabilities and Path Computation . . . . . . 18
3.3.2.1. LSP without Packet Ordering Requirements . . . . . 18
3.3.2.2. LSP with Ordering Requirements . . . . . . . . . . 19
3.3.2.3. LSP containing LSP with Ordering Requirements . . 19
3.3.3. Link Depth Limitations and Path Computation . . . . . 19
4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 20
4.1. Legacy Multipath Behavior . . . . . . . . . . . . . . . . 20
4.2. Networks without Multipath Extensions . . . . . . . . . . 21
4.2.1. Netowrks with MP Capability on all Multipath . . . . . 21
4.2.2. Netowrks with OA Capability on all Multipath . . . . . 22
4.2.3. Legacy Netowrks with Mixed MP and OA Links . . . . . . 22
4.3. Transition to Multipath Extension Support . . . . . . . . 22
4.3.1. Simple Transitions . . . . . . . . . . . . . . . . . . 23
4.3.2. More Challenging Transitions . . . . . . . . . . . . . 23
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Villamizar Expires August 30, 2012 [Page 3]
Internet-Draft MPLS TE Multipath February 2012
1. Introduction
Today the requirement to handle large aggregations of traffic, can be
handled by a number of techniques which we will collectively call
multipath. Multipath is very similar to composite link as defined in
[ITU-T.G.800], except multipath specifically excludes inverse
multiplexing. Some types of LSP, including but potentially not
limited to MPLS-TP LSP, require strict packet ordering.
Requirements to carry MPLS-TP LSP over multipath and a framework
giving a number of methods to do so are defined in
[I-D.villamizar-mpls-tp-multipath]. This document defines protocol
extensions which provide a means of supporting MPLS as a server layer
for MPLS-TP, or to carry MPLS-TP directly over a network which makes
use of multipath.
1.1. Architecture Summary
Advertisements in a link state routing protocol, such as OSPF or
ISIS, support a topology map known as a link state database (LSDB).
When traffic engineering information is included in the LSDB the
topology map is known as a TE-LSDB or traffic engineering database
(TED).
A common MPLS LSP path computation is known as a constrained shortest
path first computation (CSPF) (see [RFC3945]). Other algorithms may
be used for path computation. Constraint-based routing was first
introduced in [RFC2702]).
OSPF-TE or ISIS-TE extensions are defined in Section 2.1 and
Section 2.2. OSPF-TE or ISIS-TE advertisements serve to populate the
TE-LSDB and provide the basis for constraint-based routing path
computation. Section 3.1 describes the use of OSPF-TE or ISIS-TE
multipath extensions in routing advertisements.
RSVP-TE extensions are defined in Section 2.3 and Section 2.4.
Section 3.2 describes the use of RSVP-TE extensions in setting up LSP
including signaling constraints on LSP which contain other LSP which
specify RSVP-TE extensions.
Section 3.3 describes the constraints on LSP path computation imposed
by the advertised ordered aggregate and multipath capabilities of
links. Section 3.3.2 describes the constraints on LSP path
computation imposed by link advertisements regarding use of IP
headers in multipath traffic distribution. Section 3.3.3 describes
the impact of label stack depth limitations.
Villamizar Expires August 30, 2012 [Page 4]
Internet-Draft MPLS TE Multipath February 2012
1.2. Requirements Language
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 RFC 2119 [RFC2119].
1.3. Definitions
Please refer to [I-D.villamizar-mpls-tp-multipath].
Ordered Aggregate (OA)
An ordered aggregate (OA) requires that packets be delivered in
the order in which they were received. Please refer to [RFC3260].
Microflow
A microflow is a single instance of an application-to- application
flow. Please refer to [RFC2475]. Reordering packets within a
microflow can cause service disruption. Please refer to
[RFC2991].
Multipath Traffic Distribution
Multipath traffic distribution refers to the mechanism which
distributes traffic among a set of component links or component
lower layer paths which together comprise a multipath. No
assumptions are made about the algorithms used in multipath
traffic distribution. This document only discusses constraints of
the type of information which can be used as the basis for
multipath traffic distribution in specific circumstances.
The phrase "strict packet ordering requirements" refers to the
requirement to deliver all packet in the order that they were
received. The absence of strict packet ordering requirements does
not imply total absence of packet ordering requirements. The
requirement to avoid reordering traffic within any given microflow,
as described in [RFC2991] applies to all traffic aggregates including
all MPLS LSP.
2. Protocol Extensions
This section defined protocol extensions to OSPF-TE, ISIS-TE, and
RSVP-TE to address requirements described in
[I-D.villamizar-mpls-tp-multipath].
Two capability sub-TLV are added to two TLV that are used in both
OSPF-TE and ISIS-TE. The Multipath Node Capability sub-TLV is added
to the Node Attribute TLV (Section 2.1) The Multipath Link Capability
TLV is added to the Interface_ID (Section 2.2).
Villamizar Expires August 30, 2012 [Page 5]
Internet-Draft MPLS TE Multipath February 2012
Two TLV are added to the LSP_ATTRIBUTES object defined in [RFC5420].
2.1. Multipath Node Capability sub-TLV
The Node Attribute TLV is defined in [RFC5786]. A new sub-TLV, the
Multipath Node Capability sub-TLV, is defined for inclusion in the
Node Attribute TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Min Depth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Depth | IP Depth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Multipath Capability Sub-TLV
The fields in the Multipath Capability sub-TLV are defined as
follows.
Type
The Type field is assigned a value of IANA-TBD-1. The Type field
is a two octet value.
Length
The Length field indicates the length of the sub-TLV in octets,
excluding the Type and Length fields. The Length field is a two
octet value.
Flags
The Flags field is a two octet (16 bit) value. The following
single bit fields are assigned within this value, starting at the
most significant bit, which is the bit transmitted first.
0x8000 Ordered Aggregate Enabled
Setting the Ordered Aggregate Enabled bit indicates that an LSP
can be carried as an Ordered Aggregate Enabled on one or more
links.
0x4000 Multipath Enabled
Setting the Multipath Enabled bit indicates that an LSP can be
spread across component links at one or more multipath links.
Villamizar Expires August 30, 2012 [Page 6]
Internet-Draft MPLS TE Multipath February 2012
0x2000 IPv4 Enabled Multipath
Setting the IPv4 Enabled Multipath bit indicates that the IPv4
header information can be used in multipath load balance. The
Multipath Enabled bit must be set if the IPv4 Enabled Multipath
bit is set.
0x1000 IPv6 Enabled Multipath
Setting the IP bit indicates that the IPv6 header information
can be used in multipath load balance. The Multipath Enabled
bit must be set if the IPv6 Enabled Multipath bit is set.
0x0800 UDPIPv4 Multipath
Setting the UDPIPv4 Multipath bit indicates that the UDP port
numbers carried in UDP over IPv4 can be used in multipath load
balance. The IPv4 Enabled Multipath bit must be set if UDPIPv4
Multipath is set. If the IPv4 Enabled Multipath bit is set and
the UDPIPv4 Multipath bit is clear, then only source and
destination IP addresses are used.
0x0400 UDP/IPv6 Multipath
Setting the UDP/IPv6 Multipath bit indicates that the UDP port
numbers carried in UDP over IPv6 can be used in multipath load
balance. The IPv6 Enabled Multipath bit must be set if UDP/
IPv6 Multipath is set. The IPv4 Enabled Multipath bit must be
set if UDPIPv4 Multipath is set. If the IPv6 Enabled Multipath
bit is set and the UDP/IPv6 Multipath bit is clear, then only
source and destination IP addresses are used.
0x0200 TDPIPv4 Multipath
Setting the TDPIPv4 Multipath bit indicates that the TCP port
numbers carried in TCP over IPv4 can be used in multipath load
balance. The IPv4 Enabled Multipath bit must be set if TDPIPv4
Multipath is set. If the IPv4 Enabled Multipath bit is set and
the TDPIPv4 Multipath bit is clear, then only source and
destination IP addresses are used.
0x0100 TCP/IPv6 Multipath
Setting the TCP/IPv6 Multipath bit indicates that the TCP port
numbers carried in TCP over IPv6 can be used in multipath load
balance. The IPv6 Enabled Multipath bit must be set if TCP/
IPv6 Multipath is set. The IPv4 Enabled Multipath bit must be
set if TDPIPv4 Multipath is set. If the IPv6 Enabled Multipath
bit is set and the TCP/IPv6 Multipath bit is clear, then only
source and destination IP addresses are used.
Villamizar Expires August 30, 2012 [Page 7]
Internet-Draft MPLS TE Multipath February 2012
0x0080 Default to Multipath
Setting the Default to Multipath bit indicates that for an LSP
which does not signal a desired behavior the traffic for that
LSP will be spread across component links at one or more
multipath links. If the Default to Multipath bit is not set,
then an LSP which does not signal otherwise will be treated as
an ordered aggregate.
0x0040 Default to IP/MPLS Multipath
Setting the Default to IP/MPLS Multipath indicates that for an
LSP which does not signal a desired behavior, the IP header
information will be used in the multipath load distribution.
If the Default to IP/MPLS Multipath is clear it indicates that
the the IP header information will not be used by default.
0x0020 Variable Depth Multipath
Setting the Variable Depth Multipath bit indicates that when
multipath is enabled for a given LSP, the stack depth beyond
which multipath will not extract information for use in the
multipath load distribution can be set on a per LSP basis.
0x0010 IP Optional Multipath
Setting the IP Optional Multipath bit indicates that when
multipath is enabled for a given LSP, whether the IP header
information is used in the multipath load distribution can be
set on a per LSP basis.
The remaining bits in the Flags field are reserved.
Reserved
The Reserved field MUST be set to zero and MUST be ignored unless
implementing an extension.
Min Depth
The Min Depth field indicates the minimum stack depth which can be
supported in the multipath traffic distribution. For links which
are not PSC LSP, the Min Depth field is set to zero. For FA
advertised for PSC LSP, this field will be set to one or more.
See Section 3.1.4 for further details.
Max Depth
The Max Depth field is a one octet field indicating the maximum
label stack depth beyond which the multipath load distribution
cannot make use of further label stack entries.
Villamizar Expires August 30, 2012 [Page 8]
Internet-Draft MPLS TE Multipath February 2012
IP Depth
The IP Depth field is a one octet field indicating the maximum
label stack depth beyond which the multipath load distribution
cannot make use of IP information.
The reserved bits in the Flags field and the Reserved field MUST be
set to zero and MUST be ignored unless implementing an extension
which redefines one or more of the reserved bits. Any further
extension which redefines one or more reserved Flags bit should
maintain backwards compatibility with prior implementations.
2.2. Multipath Link Capability TLV
The Interface_ID is defined in [RFC3471]. The Interface_ID is
updated in [RFC4201] to support a form of multipath known as Link
Bundling.
A new TLV, the Multipath Link Capability TLV, is defined here. The
Multipath Link Capability TLV is optionally included in the
Interface_ID. The format of the Multipath Link Capability TLV is
identical to the Multipath Node Capability sub-TLV defined in
Section 2.1, with one exception. In the Multipath Link Capability
TLV the Type field value is IANA-TBD-2.
If a Multipath Link Capability TLV is advertised for any link, then a
Multipath Node Capability sub-TLV MUST be advertised for the node.
2.3. Contained Ordered Aggregate Attributes TLV
The LSP_ATTRIBUTES object is defined in [RFC5420]. A new Contained
Ordered Aggregate Attributes TLV is defined for the LSP_ATTRIBUTES
object. The TLV Type is IANA_TBD_3. The format is described below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | OA Depth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Contained Ordered Aggregate Attributes TLV
The fields in the Contained Ordered Aggregate Attributes TLV are
defined as follows.
Villamizar Expires August 30, 2012 [Page 9]
Internet-Draft MPLS TE Multipath February 2012
Type
The Type field is assigned a value of IANA-TBD-3. The Type field
is a two octet value.
Length
The Length field indicates the length of the sub-TLV in octets,
excluding the Type and Length fields. The Length field is a two
octet value.
Flags
The Flags field is a three octet (24 bit) value. The following
single bit fields are assigned within this value, starting at the
most significant bit, which is the bit transmitted first.
0x80 IP Multipath Allowed
Setting the IP Multipath Allowed bit indicates that it is safe
to enable the use of a potential IP payload in the multipath
traffic distribution.
0x40 May Contain IPv4
Setting the May Contain IPv4 bit indicates that IPv4 traffic
may be contained within this LSP.
0x40 May Contain IPv6
Setting the May Contain IPv6 bit indicates that IPv6 traffic
may be contained within this LSP.
The remaining bits in the Flags field are reserved.
OA Depth
The OA Depth field is set as follows
0 An OA Depth value of zero indicates that no ordered aggregates
are carried within the LSP.
1 An OA Depth value of one indicates that the LSP is an ordered
aggregate of traffic (the LSP requires strict ordering of
packets).
>1 An OA Depth value greater than one indicates that the LSP does
not have strict packet ordering requirements but contains
ordered aggregates at the label stack depth indicated.
The reserved bits in the Flags field MUST be set to zero and MUST be
ignored unless implementing an extension which redefines one or more
of the reserved bits. Any further extension which redefines one or
more reserved Flags bit should maintain backwards compatibility with
prior implementations.
Villamizar Expires August 30, 2012 [Page 10]
Internet-Draft MPLS TE Multipath February 2012
2.4. LSP Multipath Attributes TLV
The LSP_ATTRIBUTES object is defined in [RFC5420]. A new LSP
Multipath Attributes TLV is defined for the LSP_ATTRIBUTES object.
The TLV Type is IANA_TBD_4. The format is described below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP Depth | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Largest Microflow Capacities |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: LSP Multipath Attributes TLV
The fields in the LSP Multipath Attributes TLV are defined as
follows.
Type
The Type field is assigned a value of IANA-TBD-4. The Type field
is a two octet value.
Length
The Length field indicates the length of the sub-TLV in octets,
excluding the Type and Length fields. The Length field is a two
octet value.
MP Depth
The MP Depth field indicates the depth at which the Largest
Microflow Capacities parameters are applicable.
Largest Microflow Capacities
The Largest Microflow Capacities field contains, one, two, or
three IEEE 32 bit floating point values. Each value is a capacity
expressed in bytes per second.
Largest LSE Microflow
The first value, the Largest LSE Microflow, is the capacity of
the largest microflow if only the label stack entries are used
in multipath traffic distribution. If a Largest LSE Microflow
is not included, the LSP bandwidth request MUST be used.
Villamizar Expires August 30, 2012 [Page 11]
Internet-Draft MPLS TE Multipath February 2012
Largest IP Microflow
The second value, the Largest IP Microflow, if present, is the
capacity of the largest microflow if the label stack entries
and any potential IP source and destination address are used in
multipath traffic distribution. If the Largest IP Microflow is
not included, the value of the Largest LSE Microflow MUST be
used.
Largest L4 Microflow
The third, the Largest L4 Microflow, if present, is the
capacity of the largest microflow if the label stack entries
and any potential IP addresses and TCP or UDP port numbers are
used in multipath traffic distribution. If a Largest L4
Microflow is not included, the value of the Largest IP
Microflow MUST be used.
The Reserved field MUST be set to zero and MUST be ignored unless
implementing an extension which redefines all or part of this field.
Any further extension which redefines all or part of this field
should maintain backwards compatibility with prior implementations.
If one or more LSP Multipath Attributes TLV is present, a Contained
Ordered Aggregate Attributes TLV MUST be present. There SHOULD be no
more than one LSP Multipath Attributes TLV for any value of the MP
Depth field in any given LSP_ATTRIBUTES object. If additional LSP
Multipath Attributes TLV are encountered they MUST be ignored.
The value of the MP Depth field must be greater than zero and less
than the value of the OA Depth field in the Contained Ordered
Aggregate Attributes TLV, unless the OA Depth field is set to zero.
3. Multipath Extension Protocol Mechanisms
3.1. OSPF-TE and ISIS-TE Advertisement
Every node MUST advertise exactly one Multipath Node Capability sub-
TLV and may advertise zero of more Multipath Link Capability sub-TLV
as needed.
3.1.1. Node Capability Advertisement
Every LSR which is adjacent to one or more multipath link MUST
advertise a Multipath Node Capability sub-TLV (see Section 2.1). The
capabilities advertised for the node SHOULD reflect the capabilities
of the majority of multipath links adjacent to the node.
Villamizar Expires August 30, 2012 [Page 12]
Internet-Draft MPLS TE Multipath February 2012
3.1.2. Link Capability Advertisement
For all of the links whose capability does not exactly match the
Multipath Node Capability sub-TLV advertised by that same LSR, the
LSR MUST advertise a Multipath Link Capability sub-TLV (see
Section 2.2).
For all of the links whose capability does exactly match the
Multipath Node Capability sub-TLV advertised by that same LSR, the
LSR SHOULD NOT advertise a Multipath Link Capability sub-TLV (see
Section 2.2). In this case the Multipath Link Capability TLV is
redundant, but harmless.
3.1.3. Setting Max Depth and IP Depth
The Max Depth and IP Depth field are intended to capture
architectural limits. Most forwarding hardware will only use a
limited number of labels in the multipath traffic distribution. This
limit is reflected in the Max Depth field. Most forwarding hardware
will limit the number of labels that it will look past before looking
for an IP header to be used in the multipath traffic distribution.
This limit is reflected in the IP Depth field.
3.1.4. Hierarchical LSP Link Advertisement
A PSC LSP, as defined in [RFC4206] and updated in [RFC6107], may
carry other LSP. When signaling a PSC LSP that is expected to carry
MPLS-TP LSP or other LSP with strict packet reordering requirements
at some label depth, the minimum label stack depth at which an LSP
with strict packet reordering requirements can be carried must be
signaled.
A tradeoff must be considered. If allowed to look deep into the
label stack, multipath traffic distribution is able to distribute
traffic more evenly. It is impractical to carry LSP very deep in the
stack solely for this purpose. When carrying LSP that has strict
packet order requirements, the depth at which these LSP will be
carried is a network design tradeoff.
For example, if an MPLS-TP LSP is signaled as a PSC LSP, the the
depth needs to be limited to one. To directly carry an LSP that
requires strict packet ordering, the depth needs to be limited to
two, where the two label stack entries are for the MPLS LSP with no
packet order requirements other than for microflows and the contained
LSP with strict packet order requirements.
When the Forwarding Adjacency (FA) is advertised, the depth at which
the label stack will inspected indicated in signaling at setup time
Villamizar Expires August 30, 2012 [Page 13]
Internet-Draft MPLS TE Multipath February 2012
is expressed in the Min Depth field of the Multipath Link Capability
TLV.
The advertised Max Depth and IP Depth of a PSC LSP must be one less
that the minimum of the Max Depth and IP Depth of any link that the
PSC LSP traverses. The Max Depth and IP Depth are considered
independently of each other.
3.2. RSVP-TE LSP Attributes
All LSP SHOULD advertise a Contained Ordered Aggregate Attributes
TLV. LSP with strict packet order requirements MUST set the OA Depth
field to one to indicate that the LSP MUST be treated as ordered
aggregate. LSP which do not have strict packet order requirements
MUST only carry LSP whose requirements are reflected in the
containing LSP Contained Ordered Aggregate Attributes TLV and LSP
Multipath Attributes TLVs or the containing LSP MUST either resignal
appropriate TLVs using make-before-break semantics, or the contained
LSP signaling must be rejected with a PathErr message. Three cases
are described in the following subsections.
3.2.1. LSP Attributes for Ordered Aggregates
The Flags field in the Contained Ordered Aggregate Attributes TLV
MUST be set as follows.
1. If the LSP may directly contain IPv4 traffic, then the May
Contain IPv4 bit in the Flags field MUST be set.
2. If the LSP may directly contain IPv6 traffic, then the May
Contain IPv6 bit in the Flags field MUST be set.
3. If the LSP contains an LSP which has the May Contain IPv4 bit in
the Flags field then the May Contain IPv4 bit in the Flags field
MUST be set.
4. If the LSP contains an LSP which has the May Contain IPv6 bit in
the Flags field then the May Contain IPv6 bit in the Flags field
MUST be set.
5. If the LSP may contain pseudowires that do not use a pseudowire
control word, or may contain IPv4 or IPv6 traffic, then the IP
Multipath Allowed bit in the Flags field MUST be cleared.
6. If the LSP is known not to contain pseudowires that do not use a
pseudowire control word, and is known not to contain IPv4 or
IPv6 traffic, then the IP Multipath Allowed bit in the Flags
field SHOULD be set unless disallowed due to a contained LSP.
Villamizar Expires August 30, 2012 [Page 14]
Internet-Draft MPLS TE Multipath February 2012
7. If the LSP is known not to contain pseudowires that do not use a
pseudowire control word, and does not have strict packet
ordering requirements, then the IP Multipath Allowed bit in the
Flags field SHOULD be set unless disallowed due to a contained
LSP.
8. If the IP Multipath Allowed bit in the Flags is set and the LSP
has strict packet order requirements, the May Contain IPv4 and
May Contain IPv6 MUST be clear.
9. If the LSP contains any LSP with the IP Multipath Allowed bit in
the Flags field clear, then the IP Multipath Allowed bit in the
Flags field MUST be clear.
10. If the LSP contains any LSP with either the May Contain IPv4 bit
or the May Contain IPv6 bit in the Flags field set, and the
containing LSP has strict packet ordering requirements, then the
IP Multipath Allowed bit in the Flags field MUST be clear.
If the LSP does not contain other LSP, then it can only contain
pseudowire that terminate on that LSR. If the LSP does not contain
other LSP, then it should be known whether the LSP is used in an IP
LER capacity. Therefore, when a LSP does not contain other LSP, it
should always be possible to accurately set the Flags field in the
Contained Ordered Aggregate Attributes TLV.
See Section 4 for guidelines for handling LSP which contain LSP that
do not have a Contained Ordered Aggregate Attributes TLV. The most
conservative approach in this case is to clear the IP Multipath
Allowed bit and set the May Contain IPv4 bit and the May Contain IPv6
bit, however this may not always be necessary.
3.2.2. LSP Attributes for Ordered Aggregates
An LSP with strict packet order requirements SHOULD always include a
Contained Ordered Aggregate Attributes TLV. The OA Depth field MUST
be set to one. The LSP SHOULD NOT include any LSP Multipath
Attributes TLV.
3.2.3. Attributes for LSP without Packet Ordering
If an LSP does not have strict packet order constraints, then the
LSR_ATTRIBUTE object SHOULD always include a Contained Ordered
Aggregate Attributes TLV. The OA Depth MUST be either set to zero or
set to a configured value that is greater than one.
If the OA Depth is set to a configured value, then any setup attempt
for a contained LSP with a depth greater than or equal to that value
Villamizar Expires August 30, 2012 [Page 15]
Internet-Draft MPLS TE Multipath February 2012
SHOULD be rejected and a PathErr message sent. Otherwise, if a setup
attempt for a contained LSP with a depth greater that the current
value included in the containing LSP OA Depth field, then the
containing LSP MUST be rerouted with a OA Depth field value greater
than any of the contained OA Depth field values.
The values in the LSP Multipath Attributes TLV may be constrained to
upper limits by configuration. If an attempt to setup a contained
LSP would result in exceeding one of these limits, then the LSR
SHOULD reject the signaling attempt and send a PathErr message.
If an LSP does not have strict packet order constraints, then the
LSR_ATTRIBUTE object MAY contain one or more LSP Multipath Attributes
TLV. If the LSP does not contain any other LSP, then one LSP
Multipath Attributes TLV MAY be contained, with the MP Depth field
set to one. In this case, the Largest LSE Microflow in the Largest
Microflow Capacities field MUST be set to the requested bandwidth of
the LSP. The optional Largest IP Microflow and Largest L4 Microflow
MAY be included and set to configured values.
If an LSP that does not have strict packet order constraints contains
other LSP, then the LSP Multipath Attributes TLV advertised by the
set of contained LSP MUST be used to set the LSP Multipath Attributes
TLV Largest Microflow Capacities values for LSP Multipath Attributes
TLV. The value of Largest LSE Microflow, Largest IP Microflow, and
Largest L4 Microflow in the LSP Multipath Attributes TLV of the
containing LSP with an MP Depth of N cannot be less than the maximum
effective value of the same parameter for any contained LSP Multipath
Attributes TLV with an MP Depth value of N-1.
3.3. Path Computation Constraints
The RSVP-TE extensions provides a set of requirements to be met by
the links which the LSP is to traverse. This set of requirements
also serves as the basis for path computation constraints and for
admission control constraints.
3.3.1. Link Multipath Capabilities and Path Computation
Three cases are considered. An LSP may have strict ordering
constraints. An MPLS-TP LSP is an example of an LSP with strict
ordering constraints. This first type of LSP is covered in
Section 3.3.1.1. An LSP may have no ordering constraints at all
other than the constraint that microflows cannot be reordered. This
second case is covered in Section 3.3.1.2. The remaining case is
where an LSP has no ordering constraints but carries traffic for
other LSP which do have ordering constraints. This third case is
covered in Section 3.3.1.3.
Villamizar Expires August 30, 2012 [Page 16]
Internet-Draft MPLS TE Multipath February 2012
3.3.1.1. Path Computation with Ordering Constraints
For an MPLS-TP LSP or other LSP with a strict packet ordering
constraint, any link for which the Ordered Aggregate Enabled bit is
not set must be excluded from the path computation. If the Default
to Multipath bit is set on a link, then extensions to RSVP-TE to
indicate a requirement to maintain packet order must be used in
signaling to override the default.
3.3.1.2. Path Computation with No Ordering Constraint
For an MPLS LSP which has no constraint on packet ordering except
that microflows must remain in order and does not contain other LSP
with ordering constraints, any link for which the Multipath Enabled
bit is set SHOULD use an available bandwidth taken from the
"Unreserved Bandwidth" rather than the "Maximum LSP Bandwidth" (see
[RFC4201]).
For most LSP, the bandwidth requirement of the largest microflow is
not known but an upper bound is known. For example if the LSP
aggregates PW or other LSP of no more than some maximum capacity or
LSP which have signaled a microflow upper bound, then an upper bound
on the largest microflow is known. If this upper bound exceeds the
"Maximum LSP Bandwidth" of a given link, then that link SHOULD be
excluded from the path computation.
3.3.1.3. Path Computation for MPLS containing MPLS-TP
To carry LSP which have strict packet ordering requirements within
LSP that do not have strict packet ordering requirements, the label
stack depth at which multipath traffic distribution is allowed to
take information must be limited. To set up such an LSP, the minimum
label stack depth at which an MPLS-TP LSP or other LSP with strict
ordering constraints will be carried must be known.
For links which have the Variable Depth Multipath bit clear, the MPLS
LSP MUST be treated as if the containing LSP has ordering
constraints, unless the Max Depth for the link is equal to the
minimum label stack depth at which an MPLS-TP LSP or other LSP with
strict ordering constraints will be carried. If the LSP is treated
as if the containing LSP has ordering constraints, bandwidth
constraints MUST be applied as described in Section 3.3.1.1. Failing
to do so would violate the ordering constraints of contained LSP.
For links which have the Variable Depth Multipath bit set,
constraints may be applied to links in the path computation as
described in Section 3.3.1.2. The minimum label stack depth at which
an MPLS-TP LSP or other LSP with strict ordering constraints is
Villamizar Expires August 30, 2012 [Page 17]
Internet-Draft MPLS TE Multipath February 2012
carried MUST be signaled when the LSP is set up.
The minimum label stack depth at which an MPLS-TP LSP or other LSP
with strict ordering constraints is carried limits the multipath load
balance and therefore requires an additional constraint. For LSP
that cannot be further subdivided using information in IP headers
below the MPLS stack, those LSP are effectively equivalent to
microflows from a multipath load distribution standpoint. If the
largest bandwidth requirement for any such LSP carried at that depth
is known, then any link for which the "Maximum LSP Bandwidth" is less
than that bandwidth requirement SHOULD be excluded from the path
computation.
3.3.2. Link IP Capabilities and Path Computation
An MPLS-TP LSP cannot be reordered. There may be other types of LSP
with strict packet ordering requirements. If LSP with strict packet
ordering requirements carry IP, using IP headers in the multipath
load distribution would violate the packet ordering requirements.
Some LSP cannot be reordered but do not carry IP, and do not carry
payloads which could be mistaken as IP. For example, any LSP
carrying only pseudowire traffic, where all pseudowires are using a
control word carries no payloads which could be mistaken as IP.
These type of LSP can be carried within MPLS LSP that allow use of IP
header information in multipath load distribution.
3.3.2.1. LSP without Packet Ordering Requirements
Many LSP carry only IP or predominantly IP, use no hierarchy or have
little diversity in the MPLS label stack, and carry far more traffic
than can be carried over a single component link in a multipath.
Many LSP due to their high capacity, must traverse only multipath
which will use IP header information in the multipath traffic
distribution.
For these LSP, links must be excluded from the path computation which
do not have the IPv4 Enabled Multipath and IPv6 Enabled Multipath bit
set (if carrying both IPv4 and IPv6) and do not have either the
Default to IP/MPLS Multipath bit set or the IP Optional Multipath bit
set.
Hierarchical PSC LSP which require the use IP header information in
the multipath traffic distribution MUST NOT set the Ordered Aggregate
Enabled bit, MUST set the Default to IP/MPLS Multipath bit, and MUST
NOT set the VARIP bit in the FA advertisement.
Villamizar Expires August 30, 2012 [Page 18]
Internet-Draft MPLS TE Multipath February 2012
3.3.2.2. LSP with Ordering Requirements
In some cases an MPLS-TP may carry no IP traffic directly under the
label stack. For example, if only pseudowire service ([RFC3985]) is
being supported by an LSP, and all pseudowires are using a control
word, and all control and management information is carried in a
generic associated channel ([RFC5586]), then no IP traffic is carried
directly under the label stack. In this case, it is highly desirable
to signal the MPLS-TP LSP to allow IP header information to be used
in the multipath load distribution. Doing so will allow any MPLS LSP
containing this MPLS-TP LSP to allow the use of IP header information
in the multipath load distribution.
Where MPLS-TP LSP are carrying IP, for any link for which the use of
IP header information is not disabled or cannot be disabled on a per
LSP basis, that link must be excluded from the path computation.
Links which do not have to be excluded include link with the IPv4
Enabled Multipath and IPv6 Enabled Multipath bits clear, links with
the Default to IP/MPLS Multipath clear, and links with the IP
Optional Multipath bit set. For those links with the IP Optional
Multipath set, MPLS-TP LSP which carry IP MUST explicitly disable the
use of IP in the multipath load distribution in signaling if the
Default to IP/MPLS Multipath is set and SHOULD explicitly disable the
use o\ f IP in the multipath load distribution in signaling if the
Default to IP/MPLS Multipath is clear.
3.3.2.3. LSP containing LSP with Ordering Requirements
The largest effective microflow with respect to a given multipath
link can depend on whether the link can use IP header information in
the multipath traffic distribution.
If a PSC LSP will need to carry traffic which cannot use IP header
information in the multipath traffic distribution, then all links for
which this capability is supported and enabled and cannot be
disabled, must be excluded from the LSP path computation. Links
which can be included in the LSP path computation include those with
the IPv4 Enabled Multipath and IPv6 Enabled Multipath bits clear,
those with the Default to IP/MPLS Multipath clear, or those with the
VARIP set. For links with the IPv4 Enabled Multipath or IPv6 Enabled
Multipath bit set, the Default to IP/MPLS Multipath bit set, and the
VAR IP bit set, the requirement to disable use of IP in the multipath
traffic distribution must be indicated in signaling.
3.3.3. Link Depth Limitations and Path Computation
For any LSP which does not have strict packet ordering constraints,
LSP configuration SHOULD include the following parameters.
Villamizar Expires August 30, 2012 [Page 19]
Internet-Draft MPLS TE Multipath February 2012
LSP Min Depth
a minimal acceptable number of label used in multipath traffic
distribution,
LSP IP Depth
a minimal label stack depth where the IP header can be used in
multipath traffic distribution
For example, if a PSC LSP will carry LSP which in turn carry very
high capacity pseudowires using the pseudowire flow label (see
[I-D.ietf-pwe3-fat-pw]), the flow label is four labels deep. In this
case, LSP Min Depth should be configured at four or higher.
For example, if the same PSC LSP will carry LSP which carry IP
traffic with no additional labels, then the IP header is two labels
deep. In this case, LSP IP Depth should be configured at two or
higher.
For an LSP with LSP Min Depth configured, all links with Max Depth
set to a value below LSP Min Depth MUST be excluded from the LSP Path
Computation.
For an LSP with LSP IP Depth configured, all links with IP Depth set
to a value below LSP IP Depth MUST be excluded from the LSP Path
Computation.
4. Backwards Compatibility
Networks today use three forms of multipath.
1. IP ECMP, including IP ECMP at LER using more than one LSP.
2. Ethernet Link Aggregation [IEEE-802.1AX].
3. MPLS Link Bundling [RFC4201].
4.1. Legacy Multipath Behavior
IP ECMP and Ethernet Link Aggregation always distribute traffic over
the entire multipath either using information in the MPLS label
stack, or using information in a potential IP header, or using both
types of information.
One of two behaviors is assumed for link bundles. Either the link
bundles place each LSP in its entirety on a single link bundle
component link for all LSP, or link bundles distribute traffic over
the entire link bundle using the same techniques used for ECMP and
Villamizar Expires August 30, 2012 [Page 20]
Internet-Draft MPLS TE Multipath February 2012
Ethernet Link Aggregation. This second behavior is known as the "all
ones" component link (see [RFC4201]).
4.2. Networks without Multipath Extensions
Networks exist that are comprised entirely of LSR which do not
support these multipath extensions. In these networks there is no
way of telling how multipath links will behave. Since an Ethernet
Link Aggregation Goup (LAG) is advertised as an ordinary link, there
is no way to tell that it is a form of multipath.
4.2.1. Netowrks with MP Capability on all Multipath
Most large core network today rely heavily on the use of multipath.
Ethernet Link Aggregation and configure LSR to use the "all ones"
component link for all LSP. The "all ones" component link is the
default for many Link Bundling implementations used in core networks.
This is equivalent to the following setting in the Multipath Node
Capabilities sub-TLV or Multipath Link Capabilities sub-TLV.
Clear the Ordered Aggregate Enabled bit,
set the Multipath Enabled bit, set the Default to Multipath bit,
and clearing the Variable Depth Multipath bit.
If the label stack is used in the multipath traffic distribution,
set Max Depth to the number of label stack entries supported,
otherwise set it to one.
If an IP packet under the label stack can be used in the multipath
traffic distribution, set IPv4 Enabled Multipath, set IPv6 Enabled
Multipath, set Default to IP/MPLS Multipath, and set IP Depth to
the maximum number of label stack entries which can be skipped
over before finding the IP stack. Otherwise clear IPv4 Enabled
Multipath, clear IPv6 Enabled Multipath and clear Default to IP/
MPLS Multipath.
These networks can support very large LSP but cannot support LSP
which require strict packet ordering with other labels below such an
LSP, such as pseudowire labels. They may also misroute OAM packet
which use GAL (see [RFC5586]). Generally the Link Bundle
advertisements indicate a "Maximum LSP Bandwidth" that is equal to
the "Unreserved Bandwidth".
Villamizar Expires August 30, 2012 [Page 21]
Internet-Draft MPLS TE Multipath February 2012
4.2.2. Netowrks with OA Capability on all Multipath
Some networks, particularly edge networks which tend to be lower
capacity, do not use Link Aggregation, and if they use Link Bundling
at all, configure each LSR to place each LSP in its entirety on a
single link bundle component link for all LSP. Some edge equipment
only supports this link bundle behavior.
This is equivalent to the following setting in the Multipath Node
Capabilities sub-TLV or Multipath Link Capabilities sub-TLV.
Clear the Ordered Aggregate Enabled bit,
Clear the Multipath Enabled bit.
All remaining bits in the Flags field should be clear.
The Min Depth, Max Depth, and IP Depth should be set to zero.
These networks can support LSP which require strict packet ordering,
but cannot support very large LSP.
4.2.3. Legacy Netowrks with Mixed MP and OA Links
Some network may support Ethernet Link Aggregation and all or a
subset of LSR which place each LSP in its entirety on a single link
bundle component link for all LSP.
If the "Maximum LSP Bandwidth" is set as described in Section 4.2.1,
then very large LSP can be supported. Very large LSP cannot be
supported on LSR which place each LSP in its entirety on a single
link bundle component link for all LSP, but these are clearly
indicated in signaling,
In these mixed networks it is not possible to reliably support LSP
which require strict packet ordering. It is not possible to know
where Ethernet Link Aggregation is used and it is not possible to
accurately determine Link Bundling behavior on link bundles where
"Maximum LSP Bandwidth" is equal to "Unreserved Bandwidth".
4.3. Transition to Multipath Extension Support
If a Multipath Node Capability sub-TLV is not advertised (see
Section 2.1), then the LSR does not support these multipath
extensions, or is not adjacent to any multipath. This allows
detection of such nodes and if necessary application of defaults to
cover Ethernet Link Aggregation Behavior.
Villamizar Expires August 30, 2012 [Page 22]
Internet-Draft MPLS TE Multipath February 2012
4.3.1. Simple Transitions
For networks with LSR that do not support for multipath extensions,
transition is easiest if all legacy LSR support and are configured
with a common link bundling behavior. If Ethernet Link Aggregation
is not used, a single configured default is needed to cover LSR that
do not advertise a Multipath Node Capability sub-TLV.
If Ethernet Link Aggregation had been previously used on Legacy LSR,
if possible LAG should be disabled and the members of the former LAG
configured and advertised as a link bundle which uses the equivalent
"all ones" behavior.
The transition network in this case lacks the ability to determine
the largest microflow that can pass through legacy nodes, but this
was the case prior to transition for the entire network prior to
transition.
4.3.2. More Challenging Transitions
Transition is made more difficult if legacy LSR in a network support
Ethernet Link Aggregation but do not support Link Bundle. This
situation is most easily handled if a small upgrade to such an LSR
can advertise a fixed Multipath Node Capability sub-TLV giving the
characteristics of the Ethernet Link Aggregation on implementation on
that node. Absent of such cooperation, the problem can be solved by
configuration on newer LSR which allows association of a Multipath
Node Capability sub-TLV with a specific legacy router ID and possibly
a legacy router ID and link.
LSR supporting Multipath Extensions assign default values assigned by
configuration to these legacy LSR running Ethernet Link Aggregation.
These default values serve to allow LSP which require strict packet
ordering to avoid these legacy LSR.
LSR which do not support [RFC4201] may be sufficiently rare that the
ability to assign default values per legacy LSR may not be needed in
practice.
5. IANA Considerations
[ ... to be completed ... ]
The symbolic constants IANA-TBD-1 through IANA-TBD-4 need to be
replaced. Complete instructions, including identification of the
number space for each of these will be added to a later version of
this internet-draft.
Villamizar Expires August 30, 2012 [Page 23]
Internet-Draft MPLS TE Multipath February 2012
6. Security Considerations
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 [RFC5920] and
[I-D.ietf-mpls-tp-security-framework].
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[I-D.ietf-mpls-tp-security-framework]
Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP
Security Framework",
draft-ietf-mpls-tp-security-framework-01 (work in
progress), May 2011.
[I-D.ietf-pwe3-fat-pw]
Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow Aware Transport of Pseudowires
over an MPLS Packet Switched Network",
draft-ietf-pwe3-fat-pw-06 (work in progress), May 2011.
[I-D.villamizar-mpls-tp-multipath]
Villamizar, C., "Use of Multipath with MPLS-TP and MPLS",
draft-villamizar-mpls-tp-multipath-01 (work in progress),
March 2011.
[IEEE-802.1AX]
IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE
Standard for Local and Metropolitan Area Networks - Link
Aggregation", 2006, <http://standards.ieee.org/getieee802/
download/802.1AX-2008.pdf>.
[ITU-T.G.800]
ITU-T, "Unified functional architecture of transport
networks", 2007, <http://www.itu.int/rec/T-REC-G/
recommendation.asp?parent=T-REC-G.800>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
Villamizar Expires August 30, 2012 [Page 24]
Internet-Draft MPLS TE Multipath February 2012
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
Multicast Next-Hop Selection", RFC 2991, November 2000.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's
Local Addresses in OSPF Traffic Engineering (TE)
Extensions", RFC 5786, March 2010.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6107] Shiomoto, K. and A. Farrel, "Procedures for Dynamically
Signaled Hierarchical Label Switched Paths", RFC 6107,
February 2011.
Villamizar Expires August 30, 2012 [Page 25]
Internet-Draft MPLS TE Multipath February 2012
Author's Address
Curtis Villamizar (editor)
Outer Cape Cod Network Consulting
Email: curtis@occnc.com
Villamizar Expires August 30, 2012 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-24 03:25:32 |