draft-ietf-rtgwg-cl-framework-01.txt   draft-ietf-rtgwg-cl-framework-02.txt 
RTGWG S. Ning RTGWG S. Ning
Internet-Draft Tata Communications Internet-Draft Tata Communications
Intended status: Informational D. McDysan Intended status: Informational D. McDysan
Expires: February 13, 2013 Verizon Expires: April 22, 2013 Verizon
E. Osborne E. Osborne
Cisco Cisco
L. Yong L. Yong
Huawei USA Huawei USA
C. Villamizar C. Villamizar
Outer Cape Cod Network Outer Cape Cod Network
Consulting Consulting
August 12, 2012 October 19, 2012
Composite Link Framework in Multi Protocol Label Switching (MPLS) Composite Link Framework in Multi Protocol Label Switching (MPLS)
draft-ietf-rtgwg-cl-framework-01 draft-ietf-rtgwg-cl-framework-02
Abstract Abstract
This document specifies a framework for support of composite link in This document specifies a framework for support of composite link in
MPLS networks. A composite link consists of a group of homogenous or MPLS networks. A composite link consists of a group of homogenous or
non-homogenous links that have the same forward adjacency and can be non-homogenous links that have the same forward adjacency and can be
considered as a single TE link or an IP link in routing. A composite considered as a single TE link or an IP link in routing. A composite
link relies on its component links to carry the traffic over the link relies on its component links to carry the traffic over the
composite link. Applicability is described for a single pair of composite link. Applicability is described for a single pair of
MPLS-capable nodes, a sequence of MPLS-capable nodes, or a set of MPLS-capable nodes, a sequence of MPLS-capable nodes, or a set of
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 13, 2013. This Internet-Draft will expire on April 22, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Architecture Summary . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions used in this document . . . . . . . . . . . . 5 1.2. Architecture Summary . . . . . . . . . . . . . . . . . . . 4
1.2.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5 1.3. Conventions used in this document . . . . . . . . . . . . 5
2. Composite Link Key Characteristics . . . . . . . . . . . . . . 5 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Flow Identification . . . . . . . . . . . . . . . . . . . 6 1.5. Document Issues . . . . . . . . . . . . . . . . . . . . . 5
2.2. Composite Link in Control Plane . . . . . . . . . . . . . 8 2. Composite Link Key Characteristics . . . . . . . . . . . . . . 7
2.3. Composite Link in Data Plane . . . . . . . . . . . . . . . 11 2.1. Flow Identification . . . . . . . . . . . . . . . . . . . 7
3. Architecture Tradeoffs . . . . . . . . . . . . . . . . . . . . 11 2.2. Composite Link in Control Plane . . . . . . . . . . . . . 10
3.1. Scalability Motivations . . . . . . . . . . . . . . . . . 12 2.3. Composite Link in Data Plane . . . . . . . . . . . . . . . 13
3.2. Reducing Routing Information and Exchange . . . . . . . . 12 3. Architecture Tradeoffs . . . . . . . . . . . . . . . . . . . . 14
3.3. Reducing Signaling Load . . . . . . . . . . . . . . . . . 13 3.1. Scalability Motivations . . . . . . . . . . . . . . . . . 14
3.3.1. Reducing Signaling Load using LDP . . . . . . . . . . 14 3.2. Reducing Routing Information and Exchange . . . . . . . . 15
3.3.2. Reducing Signaling Load using Hierarchy . . . . . . . 14 3.3. Reducing Signaling Load . . . . . . . . . . . . . . . . . 16
3.3.3. Using Both LDP and RSVP-TE Hierarchy . . . . . . . . . 14 3.3.1. Reducing Signaling Load using LDP . . . . . . . . . . 16
3.4. Reducing Forwarding State . . . . . . . . . . . . . . . . 14 3.3.2. Reducing Signaling Load using Hierarchy . . . . . . . 17
3.5. Avoiding Route Oscillation . . . . . . . . . . . . . . . . 15 3.3.3. Using Both LDP and RSVP-TE Hierarchy . . . . . . . . . 17
4. New Challenges . . . . . . . . . . . . . . . . . . . . . . . . 16 3.4. Reducing Forwarding State . . . . . . . . . . . . . . . . 17
4.1. Control Plane Challenges . . . . . . . . . . . . . . . . . 16 3.5. Avoiding Route Oscillation . . . . . . . . . . . . . . . . 18
4.1.1. Delay and Jitter Sensitive Routing . . . . . . . . . . 17 4. New Challenges . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2. Local Control of Traffic Distribution . . . . . . . . 17 4.1. Control Plane Challenges . . . . . . . . . . . . . . . . . 19
4.1.3. Path Symmetry Requirements . . . . . . . . . . . . . . 17 4.1.1. Delay and Jitter Sensitive Routing . . . . . . . . . . 19
4.1.4. Requirements for Contained LSP . . . . . . . . . . . . 18 4.1.2. Local Control of Traffic Distribution . . . . . . . . 20
4.1.5. Retaining Backwards Compatibility . . . . . . . . . . 19 4.1.3. Path Symmetry Requirements . . . . . . . . . . . . . . 20
4.2. Data Plane Challenges . . . . . . . . . . . . . . . . . . 19 4.1.4. Requirements for Contained LSP . . . . . . . . . . . . 21
4.2.1. Very Large LSP . . . . . . . . . . . . . . . . . . . . 20 4.1.5. Retaining Backwards Compatibility . . . . . . . . . . 21
4.2.2. Very Large Microflows . . . . . . . . . . . . . . . . 20 4.2. Data Plane Challenges . . . . . . . . . . . . . . . . . . 22
4.2.3. Traffic Ordering Constraints . . . . . . . . . . . . . 20 4.2.1. Very Large LSP . . . . . . . . . . . . . . . . . . . . 22
4.2.4. Accounting for IP and LDP Traffic . . . . . . . . . . 21 4.2.2. Very Large Microflows . . . . . . . . . . . . . . . . 23
4.2.5. IP and LDP Limitations . . . . . . . . . . . . . . . . 21 4.2.3. Traffic Ordering Constraints . . . . . . . . . . . . . 23
5. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 22 4.2.4. Accounting for IP and LDP Traffic . . . . . . . . . . 24
5.1. Link Bundling . . . . . . . . . . . . . . . . . . . . . . 22 4.2.5. IP and LDP Limitations . . . . . . . . . . . . . . . . 24
5.2. Classic Multipath . . . . . . . . . . . . . . . . . . . . 24 5. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 25
5.1. Link Bundling . . . . . . . . . . . . . . . . . . . . . . 25
6. Mechanisms Proposed in Other Documents . . . . . . . . . . . . 24 5.2. Classic Multipath . . . . . . . . . . . . . . . . . . . . 26
6.1. Loss and Delay Measurement . . . . . . . . . . . . . . . . 24 6. Mechanisms Proposed in Other Documents . . . . . . . . . . . . 27
6.2. Link Bundle Extensions . . . . . . . . . . . . . . . . . . 25 6.1. Loss and Delay Measurement . . . . . . . . . . . . . . . . 27
6.3. Fat PW and Entropy Labels . . . . . . . . . . . . . . . . 26 6.2. Link Bundle Extensions . . . . . . . . . . . . . . . . . . 28
6.4. Multipath Extensions . . . . . . . . . . . . . . . . . . . 26 6.3. Pseudowire Flow and MPLS Entropy Labels . . . . . . . . . 28
7. Required Protocol Extensions and Mechanisms . . . . . . . . . 27 6.4. Multipath Extensions . . . . . . . . . . . . . . . . . . . 29
7.1. Brief Review of Requirements . . . . . . . . . . . . . . . 27 7. Required Protocol Extensions and Mechanisms . . . . . . . . . 30
7.2. Required Document Coverage . . . . . . . . . . . . . . . . 28 7.1. Brief Review of Requirements . . . . . . . . . . . . . . . 30
7.2.1. Component Link Grouping . . . . . . . . . . . . . . . 28 7.2. Proposed Document Coverage . . . . . . . . . . . . . . . . 31
7.2.2. Delay and Jitter Extensions . . . . . . . . . . . . . 29 7.2.1. Component Link Grouping . . . . . . . . . . . . . . . 31
7.2.3. Path Selection and Admission Control . . . . . . . . . 29 7.2.2. Delay and Jitter Extensions . . . . . . . . . . . . . 32
7.2.4. Dynamic Multipath Balance . . . . . . . . . . . . . . 30 7.2.3. Path Selection and Admission Control . . . . . . . . . 32
7.2.5. Frequency of Load Balance . . . . . . . . . . . . . . 30 7.2.4. Dynamic Multipath Balance . . . . . . . . . . . . . . 33
7.2.6. Inter-Layer Communication . . . . . . . . . . . . . . 30 7.2.5. Frequency of Load Balance . . . . . . . . . . . . . . 33
7.2.7. Packet Ordering Requirements . . . . . . . . . . . . . 31 7.2.6. Inter-Layer Communication . . . . . . . . . . . . . . 33
7.2.8. Minimally Disruption Load Balance . . . . . . . . . . 31 7.2.7. Packet Ordering Requirements . . . . . . . . . . . . . 34
7.2.9. Path Symmetry . . . . . . . . . . . . . . . . . . . . 31 7.2.8. Minimally Disruption Load Balance . . . . . . . . . . 34
7.2.10. Performance, Scalability, and Stability . . . . . . . 32 7.2.9. Path Symmetry . . . . . . . . . . . . . . . . . . . . 34
7.2.11. IP and LDP Traffic . . . . . . . . . . . . . . . . . . 32 7.2.10. Performance, Scalability, and Stability . . . . . . . 35
7.2.12. LDP Extensions . . . . . . . . . . . . . . . . . . . . 32 7.2.11. IP and LDP Traffic . . . . . . . . . . . . . . . . . . 35
7.2.13. Pseudowire Extensions . . . . . . . . . . . . . . . . 33 7.2.12. LDP Extensions . . . . . . . . . . . . . . . . . . . . 36
7.2.14. Multi-Domain Composite Link . . . . . . . . . . . . . 33 7.2.13. Pseudowire Extensions . . . . . . . . . . . . . . . . 36
7.3. Open Issues Regarding Requirements . . . . . . . . . . . . 34 7.2.14. Multi-Domain Composite Link . . . . . . . . . . . . . 36
7.4. Framework Requirement Coverage by Protocol . . . . . . . . 34 7.3. Framework Requirement Coverage by Protocol . . . . . . . . 37
7.4.1. OSPF-TE and ISIS-TE Protocol Extensions . . . . . . . 35 7.3.1. OSPF-TE and ISIS-TE Protocol Extensions . . . . . . . 37
7.4.2. PW Protocol Extensions . . . . . . . . . . . . . . . . 35 7.3.2. PW Protocol Extensions . . . . . . . . . . . . . . . . 37
7.4.3. LDP Protocol Extensions . . . . . . . . . . . . . . . 35 7.3.3. LDP Protocol Extensions . . . . . . . . . . . . . . . 37
7.4.4. RSVP-TE Protocol Extensions . . . . . . . . . . . . . 35 7.3.4. RSVP-TE Protocol Extensions . . . . . . . . . . . . . 37
7.4.5. RSVP-TE Path Selection Changes . . . . . . . . . . . . 35 7.3.5. RSVP-TE Path Selection Changes . . . . . . . . . . . . 37
7.4.6. RSVP-TE Admission Control and Preemption . . . . . . . 35 7.3.6. RSVP-TE Admission Control and Preemption . . . . . . . 38
7.4.7. Flow Identification and Traffic Balance . . . . . . . 35 7.3.7. Flow Identification and Traffic Balance . . . . . . . 38
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . . 36 11.1. Normative References . . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . . 37 11.2. Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
Composite Link functional requirements are specified in Composite Link functional requirements are specified in
[I-D.ietf-rtgwg-cl-requirement]. Composite Link use cases are [I-D.ietf-rtgwg-cl-requirement]. Composite Link use cases are
described in [I-D.ietf-rtgwg-cl-use-cases]. This document specifies described in [I-D.ietf-rtgwg-cl-use-cases]. This document specifies
a framework to meet these requirements. a framework to meet these requirements.
This document describes a composite link framework in the context of
MPLS networks using an IGP-TE and RSVP-TE MPLS control plane with
GMPLS extensions [RFC3209] [RFC3630] [RFC3945] [RFC5305].
Specific protocol solutions are outside the scope of this document,
however a framework for the extension of existing protocols is
provided. Backwards compatibility is best achieved by extending
existing protocols where practical rather than inventing new
protocols. The focus is on examining where existing protocol
mechanisms fall short with respect to [I-D.ietf-rtgwg-cl-requirement]
and on the types of extensions that will be required to accommodate
functionality that is called for in [I-D.ietf-rtgwg-cl-requirement].
1.1. Background
Classic multipath, including Ethernet Link Aggregation has been Classic multipath, including Ethernet Link Aggregation has been
widely used in today's MPLS networks [RFC4385][RFC4928]. Classic widely used in today's MPLS networks [RFC4385][RFC4928]. Classic
multipath using non-Ethernet links are often advertised using MPLS multipath using non-Ethernet links are often advertised using MPLS
Link bundling. A link bundle [RFC4201] bundles a group of Link bundling. A link bundle [RFC4201] bundles a group of
homogeneous links as a TE link to make IGP-TE information exchange homogeneous links as a TE link to make IGP-TE information exchange
and RSVP-TE signaling more scalable. A composite link allows and RSVP-TE signaling more scalable. A composite link allows
bundling non-homogenous links together as a single logical link. The bundling non-homogenous links together as a single logical link. The
motivations for using a composite link are descried in motivations for using a composite link are descried in
[I-D.ietf-rtgwg-cl-requirement] and [I-D.ietf-rtgwg-cl-use-cases]. [I-D.ietf-rtgwg-cl-requirement] and [I-D.ietf-rtgwg-cl-use-cases].
This document describes a composite link framework in the context of
MPLS networks using an IGP-TE and RSVP-TE MPLS control plane with
GMPLS extensions [RFC3209][RFC3630][RFC3945][RFC5305].
A composite link is a single logical link in MPLS network that A composite link is a single logical link in MPLS network that
contains multiple parallel component links between two MPLS LSR. contains multiple parallel component links between two MPLS LSR.
Unlike a link bundle [RFC4201], the component links in a composite Unlike a link bundle [RFC4201], the component links in a composite
link can have different properties such as cost or capacity. link can have different properties such as cost, capacity, delay, or
jitter.
Specific protocol solutions are outside the scope of this document,
however a framework for the extension of existing protocols is
provided. Backwards compatibility is best achieved by extending
existing protocols where practical rather than inventing new
protocols. The focus is on examining where existing protocol
mechanisms fall short with respect to [I-D.ietf-rtgwg-cl-requirement]
and on extensions that will be required to accommodate functionality
that is called for in [I-D.ietf-rtgwg-cl-requirement].
1.1. Architecture Summary 1.2. Architecture Summary
Networks aggregate information, both in the control plane and in the Networks aggregate information, both in the control plane and in the
data plane, as a means to achieve scalability. A tradeoff exists data plane, as a means to achieve scalability. A tradeoff exists
between the needs of scalability and the needs to identify differing between the needs of scalability and the needs to identify differing
path and link characteristics and differing requirements among flows path and link characteristics and differing requirements among flows
contained within further aggregated traffic flows. These tradeoffs contained within further aggregated traffic flows. These tradeoffs
are discussed in detail in Section 3. are discussed in detail in Section 3.
Some aspects of Composite Link requirements present challenges for Some aspects of Composite Link requirements present challenges for
which multiple solutions may exist. In Section 4 various challenges which multiple solutions may exist. In Section 4 various challenges
skipping to change at page 5, line 16 skipping to change at page 5, line 18
[I-D.ietf-rtgwg-cl-requirement] is available through MPLS Link [I-D.ietf-rtgwg-cl-requirement] is available through MPLS Link
Bundling [RFC4201]. Link bundling and other existing standards Bundling [RFC4201]. Link bundling and other existing standards
applicable to Composite Link are covered in Section 5. applicable to Composite Link are covered in Section 5.
The most straightforward means of supporting Composite Link The most straightforward means of supporting Composite Link
requirements is to extend MPLS protocols and protocol semantics and requirements is to extend MPLS protocols and protocol semantics and
in particular to extend link bundling. Extensions which have already in particular to extend link bundling. Extensions which have already
been proposed in other documents which are applicable to Composite been proposed in other documents which are applicable to Composite
Link are discussed in Section 6. Link are discussed in Section 6.
Goals of most new protocol work within IETF is to reuse existing A goal of most new protocol work within IETF is to reuse existing
protocol encapsulations and mechanisms where they meet requirements protocol encapsulations and mechanisms where they meet requirements
and extend existing mechanisms such that additional complexity is and extend existing mechanisms. This approach minimizes additional
minimized while meeting requirements and such that backwards complexity while meeting requirements and tends to preserve backwards
compatibility is preserved to the extent it is practical to do so. compatibility to the extent it is practical to do so. These goals
These goals are considered in proposing a framework for further are considered in proposing a framework for further protocol
protocol extensions and mechanisms in Section 7. extensions and mechanisms in Section 7.
1.2. Conventions used in this document 1.3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2.1. Terminology 1.4. Terminology
Terminology defined in [I-D.ietf-rtgwg-cl-requirement] is used in Terminology defined in [I-D.ietf-rtgwg-cl-requirement] is used in
this document. this document.
The abbreviation IGP-TE is used as a shorthand indicating either The abbreviation IGP-TE is used as a shorthand indicating either
OSPF-TE [RFC3630] or ISIS-TE [RFC5305]. OSPF-TE [RFC3630] or ISIS-TE [RFC5305].
1.5. Document Issues
This subsection exists solely for the purpose of focusing the RTGWG
meeting and mailing list discussions on areas within this document
that need attention in order for the document to achieve the level of
quality necessary to advance the document through the IETF process.
This subsection will be removed before work group last call.
The following issues need to be resolved.
1. The feasibility of symmetric paths for all flows is questionable.
The only case where this is practical is where LSP are smaller
than component links and where classic link bundling (not using
the all-ones component) is used. Perhaps the emphasis on this
(mis)feature should be reduced in the requirements document. See
Section 4.1.3.
2. There is a tradeoff between supporting delay optimized routing
and avoiding oscillation. This may be sufficiently covered, but
a careful review by others and comments would be beneficial.
3. Any measurement of jitter (delay variation) that is used in route
decision is likely to cause oscillation. Trying to optimize a
path to reduce jitter may be a fools errand. How do we say this
in the draft or does the existing text cover it adequately?
4. RTGWG needs to consider the possibility of using multi-topology
IGP extensions in IP and LDP routing where the topologies reflect
differing requirements (see Section 4.2.5). This idea is similar
to TOS routing, which has been discussed for decades but has
never been deployed. One possible outcome of discussion would be
to declare TOS routing out of scope.
5. The following referenced drafts have expired:
A. [I-D.kompella-mpls-rsvp-ecmp]
B. [I-D.wang-ccamp-latency-te-metric]
C. [I-D.giacalone-ospf-te-express-path]
D. [I-D.ietf-mpls-explicit-resource-control-bundle]
E. [I-D.ospf-cc-stlv]
6. Section 6.1 contains a note to co-authors suggesting that
reference to [I-D.giacalone-ospf-te-express-path] be dropped.
The co-authors and WG should consider this, and if there is
agreement, drop it.
7. Clarification of what we intend to do with Multi-Domain Composite
Link is needed in Section 7.2.14.
8. The following topics in the requirements document are not
addressed. Since they are explicitly mentioned in the
requirements document some mention of how they are supported is
needed, even if to say nothing needs to be done. If we conclude
any particular topic is irrelevant, maybe the topic should be
removed from the requirement document. At that point we could
add the management requirements that have come up and were
missed.
A. L3VPN RFC 4364, RFC 4797, L2VPN RFC 4664, VPWS, VPLS RFC
4761, RFC 4762 and VPMS VPMS Framework
(draft-ietf-l2vpn-vpms-frmwk-requirements) are referenced in
the requirements document "Assumptions" section. It is not
clear what additional Composite Link requirements these
references imply, if any. If no additional requirements are
implied, then these references are considered to be
informational only.
B. Migration (incremental deployment) may not be adequately
covered in Section 4.1.5. It might also be necessary to say
more here on performance, scalability, and stability as it
related to migration. Comments on this from co-authors or
the WG?
C. We may need a performance section in this document to
specifically address #DR6 (fast convergence), and #DR7 (fast
worst case failure convergence). We do already have
scalability discussion and make a recommendation for a
separate document. At the very least the performance section
would have to say "no worse than before, except were there
was no alternative to make it very slightly worse" (in a bit
more detail than that). It might also be helpful to better
define the nature of the performance criteria implied by #DR6
and #DR7.
The above list of issues are to be discussed at the upcoming IETF-85
meeting. Hopefully some of the issues can be resolved at the meeting
or on the RTGWG mailing list.
2. Composite Link Key Characteristics 2. Composite Link Key Characteristics
[I-D.ietf-rtgwg-cl-requirement] defines external behavior of [I-D.ietf-rtgwg-cl-requirement] defines external behavior of
Composite Links. The overall framework approach involves extending Composite Links. The overall framework approach involves extending
existing protocols in a backwards compatible manner and reusing existing protocols in a backwards compatible manner and reusing
ongoing work elsewhere in IETF where applicable, defining new ongoing work elsewhere in IETF where applicable, defining new
protocols or semantics only where necessary. Given the requirements, protocols or semantics only where necessary. Given the requirements,
and this approach of extending MPLS, Composite Link key and this approach of extending MPLS, Composite Link key
characteristics can be described in greater detail than given characteristics can be described in greater detail than given
requirements alone. requirements alone.
skipping to change at page 6, line 15 skipping to change at page 8, line 10
2.1. Flow Identification 2.1. Flow Identification
Traffic mapping to component links is a data plane operation. Traffic mapping to component links is a data plane operation.
Control over how the mapping is done may be directly dictated or Control over how the mapping is done may be directly dictated or
constrained by the control plane or by the management plane. When constrained by the control plane or by the management plane. When
unconstrained by the control plane or management plane, distribution unconstrained by the control plane or management plane, distribution
of traffic is entirely a local matter. Regardless of constraints or of traffic is entirely a local matter. Regardless of constraints or
lack or constraints, the traffic distribution is required to keep lack or constraints, the traffic distribution is required to keep
packets belonging to individual flows in sequence and meet QoS packets belonging to individual flows in sequence and meet QoS
criteria specified per LSP by either signaling or management criteria specified per LSP by either signaling or management
[RFC2475][RFC3260]. A key objective of the traffic distribution is [RFC2475] [RFC3260].
to not overload any component link, and be able to perform local
recovery when one of component link fails. Key objectives of the traffic distribution are to not overload any
component link, and to be be able to perform local recovery when a
subset of component links fails.
The network operator may have other objectives such as placing a The network operator may have other objectives such as placing a
bidirectional flow or LSP on the same component link in both bidirectional flow or LSP on the same component link in both
direction, load balance over component links, composite link energy direction, bounding delay and/or jitter, composite link energy
saving, and etc. These new requirements are described in saving, and etc. These new requirements are described in
[I-D.ietf-rtgwg-cl-requirement]. [I-D.ietf-rtgwg-cl-requirement].
Examples of means to identify a flow may in principle include: Examples of means to identify a flow may in principle include:
1. an LSP identified by an MPLS label, 1. an LSP identified by an MPLS label,
2. a sub-LSP [I-D.kompella-mpls-rsvp-ecmp] identified by an MPLS 2. a sub-LSP [I-D.kompella-mpls-rsvp-ecmp] identified by an MPLS
label, label,
skipping to change at page 6, line 49 skipping to change at page 8, line 46
6. all traffic between a pair of IP hosts, identified by an IP 6. all traffic between a pair of IP hosts, identified by an IP
source and destination pair, source and destination pair,
7. a specific connection between a pair of IP hosts, identified by 7. a specific connection between a pair of IP hosts, identified by
an IP source and destination pair, protocol, and protocol port an IP source and destination pair, protocol, and protocol port
pair, pair,
8. a layer-2 conversation within a pseudowire (PW), where the 8. a layer-2 conversation within a pseudowire (PW), where the
identification is PW payload type specific, such as Ethernet MAC identification is PW payload type specific, such as Ethernet MAC
addresses and VLAN tags within an Ethernet PW (RFC4448). addresses and VLAN tags within an Ethernet PW [RFC4448]. This is
feasible but not practical (see below).
Although in principle a layer-2 conversation within a pseudowire Although in principle a layer-2 conversation within a pseudowire
(PW), may be identified by PW payload type specific information, in (PW), may be identified by PW payload type specific information, in
practice this is impractical at LSP midpoints when PW are carried. practice this is impractical at LSP midpoints when PW are carried.
The PW ingress may provide equivalent information in a PW flow label The PW ingress may provide equivalent information in a PW flow label
[RFC6391]. Therefore, in practice, item #8 above is covered by [RFC6391]. Therefore, in practice, item #8 above is covered by
[RFC6391] and may be dropped from the list. [RFC6391] and may be dropped from the list.
An LSR must at least be capable of identifying flows based on MPLS An LSR must at least be capable of identifying flows based on MPLS
labels. Most MPLS LSP do not require that traffic carried by the LSP labels. Most MPLS LSP do not require that traffic carried by the LSP
are carried in order. MPLS-TP is a recent exception. If it is are carried in order. MPLS-TP is a recent exception. If it is
assumed that no LSP require strict packet ordering of the LSP itself assumed that no LSP require strict packet ordering of the LSP itself
(only of flows within the LSP), then the entire label stack can be (only of flows within the LSP), then the entire label stack can be
used as flow identification. If some LSP may require strict packet used as flow identification. If some LSP may require strict packet
skipping to change at page 7, line 27 skipping to change at page 9, line 27
label is used (for example, as specified by [RFC4201] when the "all- label is used (for example, as specified by [RFC4201] when the "all-
ones" component described in [RFC4201] is not used), then there may ones" component described in [RFC4201] is not used), then there may
not be adequate flow granularity to accomplish well balanced traffic not be adequate flow granularity to accomplish well balanced traffic
distribution and it will not be possible to carry LSP that are larger distribution and it will not be possible to carry LSP that are larger
than any individual component link. than any individual component link.
The number of flows can be extremely large. This may be the case The number of flows can be extremely large. This may be the case
when the entire label stack is used and is always the case when IP when the entire label stack is used and is always the case when IP
addresses are used in provider networks carrying Internet traffic. addresses are used in provider networks carrying Internet traffic.
Current practice for native IP load balancing at the time of writing Current practice for native IP load balancing at the time of writing
were documented in [RFC2991], [RFC2992]. These practices as were documented in [RFC2991] and [RFC2992]. These practices as
described, make use of IP addresses. The common practices were described, make use of IP addresses.
The common practices described in [RFC2991] and [RFC2992] were
extended to include the MPLS label stack and the common practice of extended to include the MPLS label stack and the common practice of
looking at IP addresses within the MPLS payload. These extended looking at IP addresses within the MPLS payload. These extended
practices are described in [RFC4385] and [RFC4928] due to their practices require that pseudowires use a PWE3 Control Word and are
impact on pseudowires without a PWE3 Control Word. Additional detail described in [RFC4385] and [RFC4928]. Additional detail on current
on current multipath practices can be found in the appendices of multipath practices can be found in the appendices of
[I-D.ietf-rtgwg-cl-use-cases]. [I-D.ietf-rtgwg-cl-use-cases].
Using only the top label supports too coarse a traffic balance. Using only the top label supports too coarse a traffic balance.
Using the full label stack or IP addresses as flow identification Prior to MPLS Entropy Label [I-D.ietf-mpls-entropy-label] using the
provides a sufficiently fine traffic balance, but is capable of full label stack was also too coarse. Using the full label stack and
identifying such a high number of distinct flows, that a technique of IP addresses as flow identification provides a sufficiently fine
grouping flows, such as hashing on the flow identification criteria, traffic balance, but is capable of identifying such a high number of
becomes essential to reduce the stored state, and is an essential distinct flows, that a technique of grouping flows, such as hashing
scaling technique. Other means of grouping flows may be possible. on the flow identification criteria, becomes essential to reduce the
stored state, and is an essential scaling technique. Other means of
grouping flows may be possible.
In summary: In summary:
1. Load balancing using only the MPLS label stack provides too 1. Load balancing using only the MPLS label stack provides too
coarse a granularity of load balance. coarse a granularity of load balance.
2. Tracking every flow is not scalable due to the extremely large 2. Tracking every flow is not scalable due to the extremely large
number of flows in provider networks. number of flows in provider networks.
3. Existing techniques, IP source and destination hash in 3. Existing techniques, IP source and destination hash in
particular, have proven in over two decades of experience to be particular, have proven in over two decades of experience to be
an excellent way of identifying groups of flows. an excellent way of identifying groups of flows.
4. If a better way to identify groups of flows is discovered, then 4. If a better way to identify groups of flows is discovered, then
that method can be used. that method can be used.
5. IP address hashing is not required, but use of this technique is 5. IP address hashing is not required, but use of this technique is
strongly encouraged given the technique's long history of strongly encouraged given the technique's long history of
successful deployment. successful deployment.
MPLS Entropy Label [I-D.ietf-mpls-entropy-label] provides a means of
the entropy from information that would require deeper packet
inspection, such as inspection of IP addresses, and putting that
entropy in the form of a hashed value into the label stack. Midpoint
LSR that understand the Entropy Label Indicator can make use of only
label stack information but still obtain a fine load balance
granularity.
2.2. Composite Link in Control Plane 2.2. Composite Link in Control Plane
A composite Link is advertised as a single logical interface between A composite Link is advertised as a single logical interface between
two connected routers, which forms forwarding adjacency (FA) between two connected routers, which forms forwarding adjacency (FA) between
the routers. The FA is advertised as a TE-link in a link state IGP, the routers. The FA is advertised as a TE-link in a link state IGP,
using either OSPF-TE or ISIS-TE. The IGP-TE advertised interface using either OSPF-TE or ISIS-TE. The IGP-TE advertised interface
parameters for the composite link can be preconfigured by the network parameters for the composite link can be preconfigured by the network
operator or be derived from its component links. Composite link operator or be derived from its component links. Composite link
advertisement requirements are specified in advertisement requirements are specified in
[I-D.ietf-rtgwg-cl-requirement]. [I-D.ietf-rtgwg-cl-requirement].
skipping to change at page 9, line 8 skipping to change at page 11, line 19
When an LSP is signaled using RSVP-TE, the LSP MUST be placed on the When an LSP is signaled using RSVP-TE, the LSP MUST be placed on the
component link that meets the LSP criteria indicated in the signaling component link that meets the LSP criteria indicated in the signaling
message. message.
When an LSP is signaled using LDP, the LSP MUST be placed on the When an LSP is signaled using LDP, the LSP MUST be placed on the
component link that meets the LSP criteria, if such a component link component link that meets the LSP criteria, if such a component link
is available. LDP does not support traffic engineering capabilities, is available. LDP does not support traffic engineering capabilities,
imposing restrictions on LDP use of Composite Link. See imposing restrictions on LDP use of Composite Link. See
Section 4.2.5 for further details. Section 4.2.5 for further details.
A composite link may contain non-homogeneous component links. The If the composite link solution is based on extensions to IGP-TE and
route computing engine may select one group of component links for a RSVP-TE, then in order to meet requirements defined in
LSP. The routing protocol MUST make this grouping available in the [I-D.ietf-rtgwg-cl-requirement], the following derived requirements
TE-LSDB. The route computation used in RSVP-TE MUST be extended to MUST be met.
include only the capacity of groups within a composite link which
meet LSP criteria. The signaling protocol MUST be able to indicate 1. A composite link MAY contain non-homogeneous component links.
either the criteria, or which groups may be used. A composite link The route computing engine MAY select one group of component
MUST place the LSP on a component link or group which meets or links for a LSP. The The route computing engine MUST accommodate
exceeds the LSP criteria. service objectives for a given LSP when selecting a group of
component links for a LSP.
2. The routing protocol MUST make a grouping of component links
available in the TE-LSDB, such that within each group all of the
component links have similar characteristics (the component links
are homogeneous within a group).
3. The route computation used in RSVP-TE MUST be extended to include
only the capacity of groups within a composite link which meet
LSP criteria.
4. The signaling protocol MUST be able to indicate either the
criteria, or which groups may be used.
5. A composite link MUST place each LSP on a component link or group
which meets or exceeds the LSP criteria.
Composite link capacity is aggregated capacity. LSP capacity MAY be Composite link capacity is aggregated capacity. LSP capacity MAY be
larger than individual component link capacity. Any aggregated LSP larger than individual component link capacity. Any aggregated LSP
can determine a bounds on the largest microflow that could be carried can determine a bounds on the largest microflow that could be carried
and this constraint can be handled as follows. and this constraint can be handled as follows.
1. If no information is available through signaling, management 1. If no information is available through signaling, management
plane, or configuration, the largest microflow is bound by one of plane, or configuration, the largest microflow is bound by one of
the following: the following:
A. the largest single LSP if most traffic is RSVP-TE signaled A. the largest single LSP if most traffic is RSVP-TE signaled
and further aggregated, and further aggregated,
B. the largest pseudowire if most traffic is carrying pseudowire B. the largest pseudowire if most traffic is carrying pseudowire
payloads that are aggregated within RSVP-TE LSP, payloads that are aggregated within RSVP-TE LSP,
C. or the largest source and sink interface if a large amount of C. or the largest interface or component lisk capacity carrying
IP or LDP traffic is contained within the aggregate. IP or LDP if a large amount of IP or LDP traffic is contained
within the aggregate.
If a very large amount of traffic being aggregated is IP or LDP, If a very large amount of traffic being aggregated is IP or LDP,
then the largest microflow is bound by the largest component link then the largest microflow is bound by the largest component link
on which IP traffic can arrive. For example, if an LSR is acting on which IP traffic can arrive. For example, if an LSR is acting
as an LER and IP and LDP traffic is arrving on 10 Gb/s edge as an LER and IP and LDP traffic is arriving on 10 Gb/s edge
interfaces, then no microflow larger than 10 Gb/s will be present interfaces, then no microflow larger than 10 Gb/s will be present
on the RSVP-TE LSP that aggregate traffic across the core, even on the RSVP-TE LSP that aggregate traffic across the core, even
if the core interfaces are 100 Gb/s interfaces. if the core interfaces are 100 Gb/s interfaces.
2. The prior conditions provide a bound on the largest microflow 2. The prior conditions provide a bound on the largest microflow
when no signaling extensions indicate a bounds. If an LSP is when no signaling extensions indicate a bounds. If an LSP is
aggregating smaller LSP for which the largest expected microflow aggregating smaller LSP for which the largest expected microflow
carried by the smaller LSP is signaled, then the largest carried by the smaller LSP is signaled, then the largest
microflow expected in the containing LSP (the aggregate) is the microflow expected in the containing LSP (the aggregate) is the
maximum of the largest expected microflow for any contained LSP. maximum of the largest expected microflow for any contained LSP.
skipping to change at page 10, line 43 skipping to change at page 13, line 21
than one of these two features. than one of these two features.
Individual component link may fail independently. Upon component Individual component link may fail independently. Upon component
link failure, a composite link MUST support a minimally disruptive link failure, a composite link MUST support a minimally disruptive
local repair, preempting any LSP which can no longer be supported. local repair, preempting any LSP which can no longer be supported.
Available capacity in other component links MUST be used to carry Available capacity in other component links MUST be used to carry
impacted traffic. The available bandwidth after failure MUST be impacted traffic. The available bandwidth after failure MUST be
advertised immediately to avoid looped crankback. advertised immediately to avoid looped crankback.
When a composite link is not able to transport all flows, it preempts When a composite link is not able to transport all flows, it preempts
some flows based upon local management configuration and informs the some flows based upon holding priority and informs the control plane
control plane on these preempted flows. The composite link MUST of these preempted flows. To minimize impact on traffic, the
support soft preemption [RFC5712]. This action ensures the remaining composite link MUST support soft preemption [RFC5712]. The network
traffic is transported properly. FR#10 requires that the traffic be operator SHOULD enable soft preemption. This action ensures the
restored. FR#12 requires that any change be minimally disruptive. remaining traffic is transported properly. FR#10 requires that the
These two requirements are interpreted to include preemption among traffic be restored. FR#12 requires that any change be minimally
the types of changes that must be minimally disruptive. disruptive. These two requirements are interpreted to include
preemption among the types of changes that must be minimally
disruptive.
2.3. Composite Link in Data Plane 2.3. Composite Link in Data Plane
The data plane must first identify groups of flows. Flow The data plane must identify groups of flows. Flow identification is
identification is covered in Section 2.1. Having identified groups covered in Section 2.1. Having identified groups of flows the groups
of flows the groups must be placed on individual component links. must be placed on individual component links. This step following
This second step is called traffic distribution or traffic placement. flow group identification is called traffic distribution or traffic
The two steps together are known as traffic balancing or load placement. The two steps together are known as traffic balancing or
balancing. load balancing.
Traffic distribution may be determined by or constrained by control Traffic distribution may be determined by or constrained by control
plane or management plane. Traffic distribution may be changed due plane or management plane. Traffic distribution may be changed due
to component link status change, subject to constraints imposed by to component link status change, subject to constraints imposed by
either the management plane or control plane. The distribution either the management plane or control plane. The distribution
function is local to the routers in which a composite link belongs to function is local to the routers in which a composite link belongs to
and is not specified here. and its implementation is not specified here.
When performing traffic placement, a composite link does not When performing traffic placement, a composite link does not
differentiate multicast traffic vs. unicast traffic. differentiate multicast traffic vs. unicast traffic.
In order to maintain scalability, existing data plane forwarding In order to maintain scalability, existing data plane forwarding
retains state associated with the top label only. The use of flow retains state associated with the top label only. Using UHP (UHP is
group identification is in a second step in the forwarding process. the absence of the more common PHP), zero of more labels may be POPed
Data plane forwarding makes use of the top label to select a and packet and byte counters incremented prior to processing what
composite link, or a group of components within a composite link or becomes the top label after the POP operations are completed. Flow
group identification may be a parallel step in the forwarding
process. Data plane forwarding makes use of the top label to select
a composite link, or a group of components within a composite link or
for the case where an LSP is pinned (see [RFC4201]), a specific for the case where an LSP is pinned (see [RFC4201]), a specific
component link. For those LSP for which the LSP selects only the component link. For those LSP for which the LSP selects only the
composite link or a group of components within a composite link, the composite link or a group of components within a composite link, the
load balancing makes use of the flow group identification. load balancing makes use of the set of component links selected based
on the top label, and makes use of the flow group identification to
select among that group.
The most common traffic placement techniques uses the a flow group The simplest traffic placement techniques uses a modulo operation
identification as an index into a table. The table provides an after computing a hash. This techniques has significant
indirection. The number of bits of hash is constrained to keep table disadvantages. The most common traffic placement techniques uses the
size small. While this is not the best technique, it is the most a flow group identification as an index into a table. The table
common. Better techniques exist but they are outside the scope of provides an indirection. The number of bits of hash is constrained
this document and some are considered proprietary. to keep table size small. While this is not the best technique, it
is the most common. Better techniques exist but they are outside the
scope of this document and some are considered proprietary.
Requirements to limit frequency of load balancing can be adhered to Requirements to limit frequency of load balancing can be adhered to
by keeping track of when a flow group was last moved and imposing a by keeping track of when a flow group was last moved and imposing a
minimum period before that flow group can be moved again. This is minimum period before that flow group can be moved again. This is
straightforward for a table approach. For other approaches it may be straightforward for a table approach. For other approaches it may be
less straightforward but is acheivable. less straightforward.
3. Architecture Tradeoffs 3. Architecture Tradeoffs
Scalability and stability are critical considerations in protocol Scalability and stability are critical considerations in protocol
design where protocols may be used in a large network such as today's design where protocols may be used in a large network such as today's
service provider networks. Composite Link is applicable to networks service provider networks. Composite Link is applicable to networks
which are large enough to require that traffic be split over multiple which are large enough to require that traffic be split over multiple
paths. Scalability is a major consideration for networks that reach paths. Scalability is a major consideration for networks that reach
a capacity large enough to require Composite Link. a capacity large enough to require Composite Link.
Some of the requirements of Composite Link could potentially have a Some of the requirements of Composite Link could potentially have a
negative impact on scalability. For example, Composite Link requires negative impact on scalability. This section is about architectural
additional information to be carried in situations where component tradeoffs, many motivated by the need to maintain scalability and
links differ in some significant way. stability, a need which is reflected in
[I-D.ietf-rtgwg-cl-requirement], specifically in DR#6 and DR#7.
3.1. Scalability Motivations 3.1. Scalability Motivations
In the interest of scalability information is aggregated in In the interest of scalability, information is aggregated in
situations where information about a large amount of network capacity situations where information about a large amount of network capacity
or a large amount of network demand provides is adequate to meet or a large amount of network demand provides is adequate to meet
requirements. Routing information is aggregated to reduce the amount requirements. Routing information is aggregated to reduce the amount
of information exchange related to routing and to simplify route of information exchange related to routing and to simplify route
computation (see Section 3.2). computation (see Section 3.2).
In an MPLS network large routing changes can occur when a single In an MPLS network large routing changes can occur when a single
fault occurs. For example, a single fault may impact a very large fault occurs. For example, a single fault may impact a very large
number of LSP traversing a given link. As new LSP are signaled to number of LSP traversing a given link. As new LSP are signaled to
avoid the fault, resources are consumed elsewhere, and routing avoid the fault, resources are consumed elsewhere, and routing
protocol announcements must flood the resource changes. If protocol announcements must flood the resource changes. If
protection is in place, there is less urgency to converging quickly. protection is in place, there is less urgency to converging quickly.
If multiple faults occur that are not covered by shared risk groups If multiple faults occur that are not covered by shared risk groups
(SRG), then some protection may fail, adding urgency to converging (SRG), then some protection may fail, adding urgency to converging
quickly even where protection was deployed. quickly even where protection is deployed.
Reducing the amount of information allows the exchange of information Reducing the amount of information allows the exchange of information
during a large routing change to be accomplished more quickly and during a large routing change to be accomplished more quickly and
simplifies route computation. Simplifying route computation improves simplifies route computation. Simplifying route computation improves
convergence time after very significant network faults which cannot convergence time after very significant network faults which cannot
be handled by preprovisioned or precomputed protection mechanisms. be handled by preprovisioned or precomputed protection mechanisms.
Aggregating smaller LSP into larger LSP is a means to reduce path Aggregating smaller LSP into larger LSP is a means to reduce path
computation load and reduce RSVP-TE signaling (see Section 3.3). computation load and reduce RSVP-TE signaling (see Section 3.3).
Neglecting scaling issues can result in performance issues, such as Neglecting scaling issues can result in performance issues, such as
slow convergence. Neglecting scaling in some cases can result in slow convergence. Neglecting scaling in some cases can result in
networks which perform so poorly as to become unstable. networks which perform so poorly as to become unstable.
3.2. Reducing Routing Information and Exchange 3.2. Reducing Routing Information and Exchange
Link bundling at the very least provides a means of aggregating Link bundling provides a means of aggregating control plane
control plane information. Even where the all-ones component link information. Even where the all-ones component link supported by
supported by link bundling is not used, the amount of control link bundling is not used, the amount of control information is
information is reduced by the average number of component links in a reduced by the number of component links in a bundle.
bundle.
Fully deaggregating link bundle information would negate this Fully deaggregating link bundle information would negate this
benefit. If there is a need to deaggregate, such as to distinguish benefit. If there is a need to deaggregate, such as to distinguish
between groups of links within specified ranges of delay, then no between groups of links within specified ranges of delay, then no
more deaggregation than is necessary should be done. more deaggregation than is necessary should be done.
For example, in supporting the requirement for heterogeneous For example, in supporting the requirement for heterogeneous
component links, it makes little sense to fully deaggregate link component links, it makes little sense to fully deaggregate link
bundles when adding support for groups of component links with common bundles when adding support for groups of component links with common
attributes within a link bundle can maintain most of the benefit of attributes within a link bundle can maintain most of the benefit of
skipping to change at page 13, line 29 skipping to change at page 16, line 14
require link readvertisement. For example, if delay measurements require link readvertisement. For example, if delay measurements
include queuing delay, then a much more coarse granularity of delay include queuing delay, then a much more coarse granularity of delay
measurement would be called for than if the delay does not include measurement would be called for than if the delay does not include
queuing and is dominated by geographic delay (speed of light delay). queuing and is dominated by geographic delay (speed of light delay).
3.3. Reducing Signaling Load 3.3. Reducing Signaling Load
Aggregating traffic into very large hierarchical LSP in the core very Aggregating traffic into very large hierarchical LSP in the core very
substantially reduces the number of LSP that need to be signaled and substantially reduces the number of LSP that need to be signaled and
the number of path computations any given LSR will be required to the number of path computations any given LSR will be required to
perform when a major network fault occurs. perform when a network fault occurs.
In the extreme, applying MPLS to a very large network without In the extreme, applying MPLS to a very large network without
hierarchy could exceed the 20 bit label space. For example, in a hierarchy could exceed the 20 bit label space. For example, in a
network with 4,000 nodes, with 2,000 on either side of a cutset, network with 4,000 nodes, with 2,000 on either side of a cutset,
would have 4,000,000 LSP crossing the cutset. Even in a degree four would have 4,000,000 LSP crossing the cutset. Even in a degree four
cutset, an uneven distribution of LSP across the cutset, or the loss cutset, an uneven distribution of LSP across the cutset, or the loss
of one link would result in a need to exceed the size of the label of one link would result in a need to exceed the size of the label
space. Among provider networks, 4,000 access nodes is not at all space. Among provider networks, 4,000 access nodes is not at all
large. large. Hierarchy is an absolute requirement if all access nodes were
interconnected in such a network.
In less extreme cases, having each node terminate hundreds of LSP to In less extreme cases, having each node terminate hundreds of LSP to
achieve a full mesh creates a very large computational load. The achieve a full mesh creates a very large computational load.
time complexity of one CSPF computation is order(N log N), where L is Computational complexity is a function of the number of nodes (N) and
proportional to N, and N and L are the number of nodes and number of links (L) in a topology, and the number of LSP that need to be set
links, respectively. If each node must perform order(N) computations up. In the common case where L is proportional to N (relatively
when a fault occurs, then the computational load increases as constant node degree with growth), the time complexity of one CSPF
order(N^2 log N) as the number of nodes increases. In practice at computation is order(N log N). If each node must perform order(N)
the time of writing, this imposes a limit of a few hundred nodes in a computations when a fault occurs, then the computational load
full mesh of MPLS LSP before the computational load is sufficient to increases as order(N^2 log N) as the number of nodes increases (where
result in unacceptable convergence times. "^" is the power of operator and "N^2" is read "N-squared"). In
practice at the time of writing, this imposes a limit of a few
hundred nodes in a full mesh of MPLS LSP before the computational
load is sufficient to result in unacceptable convergence times.
Two solutions are applied to reduce the amount of RSVP-TE signaling. Two solutions are applied to reduce the amount of RSVP-TE signaling.
Both involve subdividing the MPLS domain into a core and a set of Both involve subdividing the MPLS domain into a core and a set of
regions. regions.
3.3.1. Reducing Signaling Load using LDP 3.3.1. Reducing Signaling Load using LDP
LDP can be used for edge-to-edge LSP, using RSVP-TE to carry the LDP LDP can be used for edge-to-edge LSP, using RSVP-TE to carry the LDP
intra-core traffic and also optionally also using RSVP-TE to carry intra-core traffic and also optionally also using RSVP-TE to carry
the LDP intra-region traffic within each region. LDP does not the LDP intra-region traffic within each region. LDP does not
skipping to change at page 15, line 14 skipping to change at page 18, line 5
to other edge nodes. The edge nodes also require 100 intra-region to other edge nodes. The edge nodes also require 100 intra-region
LSP. Within the core, if the core has only 3 attachments to each LSP. Within the core, if the core has only 3 attachments to each
region the core LSR have less than 100 intra-core LSP. At the border region the core LSR have less than 100 intra-core LSP. At the border
cutset between the core and a given region, in this example there are cutset between the core and a given region, in this example there are
100 edge nodes with inter-region LSP crossing that cutset, destined 100 edge nodes with inter-region LSP crossing that cutset, destined
to 900 other edge nodes. That yields forwarding state for on the to 900 other edge nodes. That yields forwarding state for on the
order of 90,000 LSP at the border cutset. These same routers need order of 90,000 LSP at the border cutset. These same routers need
only reroute well under 200 LSP when a multiple fault occurs, as long only reroute well under 200 LSP when a multiple fault occurs, as long
as only links are affected and a border LSR does not go down. as only links are affected and a border LSR does not go down.
In the core, the forwarding state is greatly reduced. If inter- Interior to the core, the forwarding state is greatly reduced. If
region LSP have different characteristics, it makes sense to make use inter-region LSP have different characteristics, it makes sense to
of aggregates with different characteristics. Rather than exchange make use of aggregates with different characteristics. Rather than
information about every inter-region LSP within the intra-core LSP it exchange information about every inter-region LSP within the intra-
makes more sense to use multiple intra-core LSP between pairs of core core LSP it makes more sense to use multiple intra-core LSP between
nodes, each aggregating sets of inter-region LSP with common pairs of core nodes, each aggregating sets of inter-region LSP with
characteristics or common requirements. common characteristics or common requirements.
3.5. Avoiding Route Oscillation 3.5. Avoiding Route Oscillation
Networks can become unstable when a feedback loop exists such that Networks can become unstable when a feedback loop exists such that
moving traffic to a link causes a metric such as delay to increase, moving traffic to a link causes a metric such as delay to increase,
which then causes traffic to move elsewhere. For example, the which then causes traffic to move elsewhere. For example, the
original ARPANET routing used a delay based cost metric and proved original ARPANET routing used a delay based cost metric and proved
prone to route oscillations [DBP]. prone to route oscillations [DBP].
Delay may be used as a constraint in routing for high priority Delay may be used as a constraint in routing for high priority
traffic, where the movement of traffic cannot impact the delay. The traffic, when this high priority traffic makes a minor contribution
safest way to measure delay is to make measurements based on traffic to total load, such that the movement of the high priority traffic
which is prioritized such that it is queued ahead of the traffic has a small impact on the delay experienced by other high priority
which will be affected. This is a reasonable measure of delay for traffic. The safest way to measure delay is to make measurements
high priority traffic for which constraints have been set which allow based on traffic which is prioritized such that it is queued ahead of
this type of traffic to consume only a fraction of link capacities the lower priority traffic which will be affected if high priority
with the remaining capacity available to lower priority traffic. traffic is moved. The amount of high priority traffic must be
constrained to consume a fraction of link capacities with the
remaining capacity available to lower priority traffic.
Any measurement of jitter (delay variation) that is used in route Any measurement of jitter (delay variation) that is used in route
decision is likely to cause oscillation. Jitter that is caused by decision is likely to cause oscillation. Jitter that is caused by
queuing effects and cannot be measured using a very high priority queuing effects and cannot be measured using a very high priority
measurement traffic flow. measurement traffic flow.
It may be possible to find links with constrained queuing delay or It may be possible to find links with constrained queuing delay or
jitter using a theoretical maximum or a probability based bound on jitter using a theoretical maximum or a probability based bound on
queuing delay or jitter at a given priority based on the types and queuing delay or jitter at a given priority based on the types and
amounts of traffic accepted and combining that theoretical limit with amounts of traffic accepted and combining that theoretical limit with
a measured delay at very high priority. a measured delay at very high priority. Using delay or jitter as
path metrics without creating oscillations is challenging.
Instability can occur due to poor performance and interaction with Instability can occur due to poor performance and interaction with
protocol timers. In this way a computational scaling problem can protocol timers. In this way a computational scaling problem can
become a stability problem when a network becomes sufficiently large. become a stability problem when a network becomes sufficiently large.
For this reason, [I-D.ietf-rtgwg-cl-requirement] has a number of
requirements focusing on minimally impacting scalability.
4. New Challenges 4. New Challenges
New technical challenges are posed by [I-D.ietf-rtgwg-cl-requirement] New technical challenges are posed by [I-D.ietf-rtgwg-cl-requirement]
in both the control plane and data plane. in both the control plane and data plane.
Among the more difficult challenges are the following. Among the more difficult challenges are the following.
1. requirements related delay or jitter (see Section 4.1.1), 1. The requirements related to delay or jitter conflict with
requirements for scalability and stability (see Section 4.1.1),
2. the combination of ingress control over LSP placement and 2. The combination of ingress control over LSP placement and
retaining an ability to move traffic as demands dictate can pose retaining an ability to move traffic as demands dictate can pose
challenges and such requirements can even be conflicting (see challenges and such requirements can even be conflicting (see
target="sect.local-control" />), Section 4.1.2),
3. path symmetry requires extensions and is particularly challenging 3. Path symmetry requires extensions and is particularly challenging
for very large LSP (see Section 4.1.3), for very large LSP (see Section 4.1.3),
4. accommodating a very wide range of requirements among contained 4. Accommodating a very wide range of requirements among contained
LSP can lead to inefficiency if the most stringent requirements LSP can lead to inefficiency if the most stringent requirements
are reflected in aggregates, or reduce scalability if a large are reflected in aggregates, or reduce scalability if a large
number of aggregates are used to provide a too fine a reflection number of aggregates are used to provide a too fine a reflection
of the requirements in the contained LSP (see Section 4.1.4), of the requirements in the contained LSP (see Section 4.1.4),
5. backwards compatibility is somewhat limited due to the need to 5. Backwards compatibility is somewhat limited due to the need to
accommodate legacy multipath interfaces which provide too little accommodate legacy multipath interfaces which provide too little
information regarding their configured default behavior, and information regarding their configured default behavior, and
legacy LSP which provide too little information regarding their legacy LSP which provide too little information regarding their
requirements (see Section 4.1.5), LSP requirements (see Section 4.1.5),
6. data plane challenges include those of accommodating very large 6. Data plane challenges include those of accommodating very large
LSP, large microflows, traffic ordering constraints imposed by a LSP, large microflows, traffic ordering constraints imposed by a
subsent of LSP, and accounting for IP and LDP traffic (see subset of LSP, and accounting for IP and LDP traffic (see
Section 4.2). Section 4.2).
4.1. Control Plane Challenges 4.1. Control Plane Challenges
Some of the control plane requirements are particularly challenging. Some of the control plane requirements are particularly challenging.
Handling large flows which aggregate smaller flows must be Handling large flows which aggregate smaller flows must be
accomplished with minimal impact on scalability. Potentially accomplished with minimal impact on scalability. Potentially
conflicting are requirements for jitter and requirements for conflicting are requirements for jitter and requirements for
stability. Potentially conflicting are the requirements for ingress stability. Potentially conflicting are the requirements for ingress
control of a large number of parameters, and the requirements for control of a large number of parameters, and the requirements for
skipping to change at page 17, line 42 skipping to change at page 20, line 33
node immediately adjacent to a component link should have a high node immediately adjacent to a component link should have a high
degree of control over how traffic is distributed, as long as network degree of control over how traffic is distributed, as long as network
performance objectives are met. Particularly relevant are FR#18 and performance objectives are met. Particularly relevant are FR#18 and
FR#19. FR#19.
The requirements to allow local control are potentially in conflict The requirements to allow local control are potentially in conflict
with requirement FR#21 which gives full control of component link with requirement FR#21 which gives full control of component link
select to the LSP ingress. While supporting this capability is select to the LSP ingress. While supporting this capability is
mandatory, use of this feature is optional per LSP. mandatory, use of this feature is optional per LSP.
A given network deployment will have to consider this pair of A given network deployment will have to consider this set of
conflicting requirements and make appropriate use of local control of conflicting requirements and make appropriate use of local control of
traffic placement and ingress control of traffic placement to best traffic placement and ingress control of traffic placement to best
meet network requirements. meet network requirements.
4.1.3. Path Symmetry Requirements 4.1.3. Path Symmetry Requirements
Requirement FR#21 in [I-D.ietf-rtgwg-cl-requirement] includes a Requirement FR#21 in [I-D.ietf-rtgwg-cl-requirement] includes a
provision to bind both directions of a bidirectional LSP to the same provision to bind both directions of a bidirectional LSP to the same
component. This is easily achieved if the LSP is directly signaled component. This is easily achieved if the LSP is directly signaled
across a composite link. This is not as easily achieved if a set of across a composite link. This is not as easily achieved if a set of
LSP with this requirement are signaled over a large hierarchical LSP LSP with this requirement are signaled over a large hierarchical LSP
which is in turn carried over a composite link. The basis for load which is in turn carried over a composite link. The basis for load
distribution in such as case is the label stack. The labels in distribution in such as case is the label stack. The labels in
either direction are completely independent. either direction are completely independent.
This could be accommodated if the ingress, egress, and all midpoints This could be accommodated if the ingress, egress, and all midpoints
of the hierarchical LSP make use of an entropy label in the of the hierarchical LSP make use of an entropy label in the
distribution, and use only that entropy label. A solution for this distribution, and the ingress use a fixed value per contained LSP in
problem may add complexity with very little benefit. There is little the entropy label. A solution for this problem may add complexity
or no true benefit of using symmetrical paths rather than component with very little benefit. There is little or no true benefit of
links of identical characteristics. using symmetrical paths rather than component links of identical
characteristics.
Traffic symmetry and large LSP capacity are a second pair of Traffic symmetry and large LSP capacity are a second pair of
conflicting requirements. Any given LSP can meet one of these two conflicting requirements. Any given LSP can meet one of these two
requirements but not both. A given network deployment will have to requirements but not both. A given network deployment will have to
make appropriate use of each of these features to best meet network make appropriate use of each of these features to best meet network
requirements. requirements.
4.1.4. Requirements for Contained LSP 4.1.4. Requirements for Contained LSP
[I-D.ietf-rtgwg-cl-requirement] calls for new LSP constraints. These [I-D.ietf-rtgwg-cl-requirement] calls for new LSP constraints. These
skipping to change at page 20, line 4 skipping to change at page 22, line 45
the all-ones component to identify such link bundles after having the all-ones component to identify such link bundles after having
signaled at least one LSP. Whether any LSR collects this information signaled at least one LSP. Whether any LSR collects this information
on legacy LSR and makes use of it to set defaults, is an on legacy LSR and makes use of it to set defaults, is an
implementation choice. implementation choice.
4.2. Data Plane Challenges 4.2. Data Plane Challenges
Flow identification is briefly discussed in Section 2.1. Traffic Flow identification is briefly discussed in Section 2.1. Traffic
distribution is briefly discussed in Section 2.3. This section distribution is briefly discussed in Section 2.3. This section
discusses issues specific to particular requirements specified in discusses issues specific to particular requirements specified in
[I-D.ietf-rtgwg-cl-requirement]. [I-D.ietf-rtgwg-cl-requirement].
4.2.1. Very Large LSP 4.2.1. Very Large LSP
Very large LSP may exceed the capacity of any single component of a Very large LSP may exceed the capacity of any single component of a
composite link. In some cases contained LSP may exceed the capacity composite link. In some cases contained LSP may exceed the capacity
of any single component. These LSP may the use of the equivalent of of any single component. These LSP may make use of the equivalent of
the all-ones component of a link bundle, or may use a subset of the all-ones component of a link bundle, or may use a subset of
components which meet the LSP requirements. components which meet the LSP requirements.
Very large LSP can be accommodated as long as they can be subdivided Very large LSP can be accommodated as long as they can be subdivided
(see Section 4.2.2). A very large LSP cannot have a requirement for (see Section 4.2.2). A very large LSP cannot have a requirement for
symetric paths unless complex protocol extensions are proposed (see symmetric paths unless complex protocol extensions are proposed (see
Section 2.2 and Section 4.1.3). Section 2.2 and Section 4.1.3).
4.2.2. Very Large Microflows 4.2.2. Very Large Microflows
Within a very large LSP there may be very large microflows. A very Within a very large LSP there may be very large microflows. A very
large microflow is a very large flows which cannot be further large microflow is one which cannot be further subdivided and
subdivided. Flows which cannot be subdivided must be no larger that contributes a very large amount of capacity. Flows which cannot be
the capacity of any single component. subdivided must be no larger that the capacity of any single
component link.
Current signaling provides no way to specify the largest microflow Current signaling provides no way to specify the largest microflow
that a can be supported on a given link bundle in routing that a can be supported on a given link bundle in routing
advertisements. Extensions which address this are discussed in advertisements. Extensions which address this are discussed in
Section 6.4. Absent extensions of this type, traffic containing Section 6.4. Absent extensions of this type, traffic containing
microflows that are too large for a given composite link may be microflows that are too large for a given composite link may be
present. There is no data plane solution for this problem that would present. There is no data plane solution for this problem that would
not require reordering traffic at the composite link egress. not require reordering traffic at the composite link egress.
Some techniques are susceptible to statistical collisions where an Some techniques are susceptible to statistical collisions where an
skipping to change at page 21, line 4 skipping to change at page 23, line 45
4.2.3. Traffic Ordering Constraints 4.2.3. Traffic Ordering Constraints
Some LSP have strict traffic ordering constraints. Most notable Some LSP have strict traffic ordering constraints. Most notable
among these are MPLS-TP LSP. In the absence of aggregation into among these are MPLS-TP LSP. In the absence of aggregation into
hierarchical LSP, those LSP with strict traffic ordering constraints hierarchical LSP, those LSP with strict traffic ordering constraints
can be placed on individual component links if there is a means of can be placed on individual component links if there is a means of
identifying which LSP have such a constraint. If LSP with strict identifying which LSP have such a constraint. If LSP with strict
traffic ordering constraints are aggregated in hierarchical LSP, the traffic ordering constraints are aggregated in hierarchical LSP, the
hierarchical LSP capacity may exceed the capacity of any single hierarchical LSP capacity may exceed the capacity of any single
component link. In such a case the load balancing for the containing component link. In such a case the load balancing may be constrained
may be constrained to look only at the top label and the first through the use of an entropy label [I-D.ietf-mpls-entropy-label].
contained label. This and related issues are discussed further in This and related issues are discussed further in Section 6.4.
Section 6.4.
4.2.4. Accounting for IP and LDP Traffic 4.2.4. Accounting for IP and LDP Traffic
Networks which carry RSVP-TE signaled MPLS traffic generally carry Networks which carry RSVP-TE signaled MPLS traffic generally carry
low volumes of native IP traffic, often only carrying control traffic low volumes of native IP traffic, often only carrying control traffic
as native IP. There is no architectural guarantee of this, it is as native IP. There is no architectural guarantee of this, it is
just how network operators have made use of the protocols. just how network operators have made use of the protocols.
[I-D.ietf-rtgwg-cl-requirement] requires that native IP and native [I-D.ietf-rtgwg-cl-requirement] requires that native IP and native
LDP be accommodated. In some networks, a subset of services may be LDP be accommodated (DR#2 and DR#3). In some networks, a subset of
carried as native IP or carried as native LDP. Today this may be services may be carried as native IP or carried as native LDP. Today
accommodated by the network operator estimating the contribution of this may be accommodated by the network operator estimating the
IP and LDP and configuring a lower set of available bandwidth figures contribution of IP and LDP and configuring a lower set of available
on the RSVP-TE advertisements. bandwidth figures on the RSVP-TE advertisements.
The only improvement that Composite Link can offer is that of The only improvement that Composite Link can offer is that of
measuring the IP and LDP traffic levels and automatically reducing measuring the IP and LDP traffic levels and automatically reducing
the available bandwidth figures on the RSVP-TE advertisements. The the available bandwidth figures on the RSVP-TE advertisements. The
measurements would have to be significantly filtered. This is measurements would have to be filtered. This is similar to a feature
similar to a feature in existing LSR, commonly known as in existing LSR, commonly known as "autobandwidth" with a key
"autobandwidth" with a key difference. In the "autobandwidth" difference. In the "autobandwidth" feature, the bandwidth request of
feature, the bandwidth request of an RSVP-TE signaled LSP is adjusted an RSVP-TE signaled LSP is adjusted in response to traffic
in response to traffic measurements. In this case the IP or LDP measurements. In this case the IP or LDP traffic measurements are
traffic measurements are used to reduce the link bandwidth directly, used to reduce the link bandwidth directly, without first
without first encapsulating in an RSVP-TE LSP. encapsulating in an RSVP-TE LSP.
This may be a subtle and perhaps even a meaningless distinction if This may be a subtle and perhaps even a meaningless distinction if
Composite Link is used to form a Sub-Path Maintenance Element (SPME). Composite Link is used to form a Sub-Path Maintenance Element (SPME).
A SPME is in practice essentially an unsignaled single hop LSP with A SPME is in practice essentially an unsignaled single hop LSP with
PHP enabled [RFC5921]. A Composite Link SPME looks very much like PHP enabled [RFC5921]. A Composite Link SPME looks very much like
classic multipath, where there is no signaling, only management plane classic multipath, where there is no signaling, only management plane
configuration creating the multipath entity (of which Ethernet Link configuration creating the multipath entity (of which Ethernet Link
Aggregation is a subset). Aggregation is a subset).
4.2.5. IP and LDP Limitations 4.2.5. IP and LDP Limitations
skipping to change at page 22, line 19 skipping to change at page 25, line 14
carrying IP and LDP within RSVP-TE LSP. carrying IP and LDP within RSVP-TE LSP.
It is also not possible to route LDP traffic differently for It is also not possible to route LDP traffic differently for
different FEC. LDP traffic engineering is specifically disallowed by different FEC. LDP traffic engineering is specifically disallowed by
[RFC3468]. It may be possible to support multi-topology IGP [RFC3468]. It may be possible to support multi-topology IGP
extensions to accommodate more than one set of criteria. If so, the extensions to accommodate more than one set of criteria. If so, the
additional IGP could be bound to the forwarding criteria, and the LDP additional IGP could be bound to the forwarding criteria, and the LDP
FEC bound to a specific IGP instance, inheriting the forwarding FEC bound to a specific IGP instance, inheriting the forwarding
criteria. Alternately, one IGP instance can be used and the LDP SPF criteria. Alternately, one IGP instance can be used and the LDP SPF
can make use of the constraints, such as delay and jitter, for a can make use of the constraints, such as delay and jitter, for a
given LDP FEC. [Note: WG needs to discuss this and decide first given LDP FEC.
whether to solve this at all and then if so, how.]
5. Existing Mechanisms 5. Existing Mechanisms
In MPLS the one mechanisms which support explicit signaling of In MPLS the one mechanism which supports explicit signaling of
multiple parallel links is Link Bundling [RFC4201]. The set of multiple parallel links is Link Bundling [RFC4201]. The set of
techniques known as "classis multipath" support no explicit techniques known as "classis multipath" support no explicit
signaling, except in two cases. In Ethernet Link Aggregation the signaling, except in two cases. In Ethernet Link Aggregation the
Link Aggregation Control Protocol (LACP) coordinates the addition or Link Aggregation Control Protocol (LACP) coordinates the addition or
removal of members from an Ethernet Link Aggregation Group (LAG). removal of members from an Ethernet Link Aggregation Group (LAG).
The use of the "all-ones" component of a link bundle indicates use of The use of the "all-ones" component of a link bundle indicates use of
classis multipath, however the ability to determine if a link bundle classis multipath, however the ability to determine if a link bundle
makes use of classis multipath is not yet supported. makes use of classis multipath is not yet supported.
5.1. Link Bundling 5.1. Link Bundling
skipping to change at page 23, line 17 skipping to change at page 26, line 11
link LSP into the IGP, since only the ingress and egress of the link link LSP into the IGP, since only the ingress and egress of the link
bundle needed to be aware of their existence, which they would be bundle needed to be aware of their existence, which they would be
aware of due to the RSVP-TE signaling used in setting up the aware of due to the RSVP-TE signaling used in setting up the
component LSP. component LSP.
While link bundling can be the basis for composite links, a While link bundling can be the basis for composite links, a
significant number of small extension needs to be added. significant number of small extension needs to be added.
1. To support link bundles of heterogeneous links, a means of 1. To support link bundles of heterogeneous links, a means of
advertising the capacity available within a group of homogeneous advertising the capacity available within a group of homogeneous
needs to be provided. links needs to be provided.
2. Attributes need to be defined to support the following parameters 2. Attributes need to be defined to support the following parameters
for the link bundle or for a group of homogeneous links. for the link bundle or for a group of homogeneous links.
A. delay range A. delay range
B. jitter (delay variation) range B. jitter (delay variation) range
C. group metric C. group metric
D. all-ones component capable D. all-ones component capable
E. capable of dynamically balancing load E. capable of dynamically balancing load
F. largest supportable microflow F. largest supportable microflow
G. abilities to support strict packet ordering requirements G. support for entropy label
within contained LSP
3. For each of the prior extended attributes, the constraint based 3. For each of the prior extended attributes, the constraint based
routing path selection needs to be extended to reflect new routing path selection needs to be extended to reflect new
constraints based on the extended attributes. constraints based on the extended attributes.
4. For each of the prior extended attributes, LSP admission control 4. For each of the prior extended attributes, LSP admission control
needs to be extended to reflect new constraints based on the needs to be extended to reflect new constraints based on the
extended attributes. extended attributes.
5. Dynamic load balance must be provided for flows within a given 5. Dynamic load balance must be provided for flows within a given
set of links with common attributes such that NPO are not set of links with common attributes such that NPO are not
violated including frequency of load balance adjustment for any violated including frequency of load balance adjustment for any
given flow. given flow.
5.2. Classic Multipath 5.2. Classic Multipath
Classic multipath is defined in [I-D.ietf-rtgwg-cl-use-cases]. Classic multipath is described in [I-D.ietf-rtgwg-cl-use-cases].
Classic multipath refers to the most common current practice in Classic multipath refers to the most common current practice in
implementation and deployment of multipath. The most common current implementation and deployment of multipath. The most common current
practice makes use of a hash on the MPLS label stack and if IPv4 or practice 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 IPv6 are indicated under the label stack, makes use of the IP source
and destination addresses [RFC4385] [RFC4928]. and destination addresses [RFC4385] [RFC4928].
Classic multipath provides a highly scalable means of load balancing. Classic multipath provides a highly scalable means of load balancing.
Adaptive multipath has proven value in assuring an even loading on Dynamic multipath has proven value in assuring an even loading on
component link and an ability to adapt to change in offerred load component link and an ability to adapt to change in offered load that
that occurs over periods of hundreds of milliseconds or more. occurs over periods of hundreds of milliseconds or more. Classic
Classic multipath scalability is due to the ability to effectively multipath scalability is due to the ability to effectively work with
work with an extremely large number of flows (IP host pairs) using an extremely large number of flows (IP host pairs) using relatively
relatively little resources (a data structure accessed using a hash little resources (a data structure accessed using a hash result as a
result as a key or using ranges of hash results). key or using ranges of hash results).
Classic multipath meets a small subset of Composite Link Classic multipath meets a small subset of Composite Link
requirements. Due to scalability of the approach, classic multipath requirements. Due to scalability of the approach, classic multipath
seems to be an excellent candidate for extension to meet the full set seems to be an excellent candidate for extension to meet the full set
of Composite Link forwarding requirements. of Composite Link forwarding requirements.
Additional detail can be found in [I-D.ietf-rtgwg-cl-use-cases]. Additional detail can be found in [I-D.ietf-rtgwg-cl-use-cases].
6. Mechanisms Proposed in Other Documents 6. Mechanisms Proposed in Other Documents
skipping to change at page 25, line 6 skipping to change at page 27, line 44
Currently there are two additional Internet-Drafts that address delay Currently there are two additional Internet-Drafts that address delay
and delay variation metrics. and delay variation metrics.
draft-wang-ccamp-latency-te-metric draft-wang-ccamp-latency-te-metric
[I-D.wang-ccamp-latency-te-metric] is designed specifically to [I-D.wang-ccamp-latency-te-metric] is designed specifically to
meet this requirement. OSPF-TE and ISIS-TE extensions are meet this requirement. OSPF-TE and ISIS-TE extensions are
defined to indicate link delay and delay variance. The RSVP-TE defined to indicate link delay and delay variance. The RSVP-TE
ERO is extended to include service level requirements. A latency ERO is extended to include service level requirements. A latency
accumulation object is defined to provide a means of verification accumulation object is defined to provide a means of verification
of the service level requirements. This draft is intended to of the service level requirements. This draft is intended to
proceed in the CCAMP WG. It is currently and individual proceed in the CCAMP WG. It is currently an individual
submission. The 03 version of this draft expired in September submission which has expired.
2012.
draft-giacalone-ospf-te-express-path draft-giacalone-ospf-te-express-path
This document proposes to extend OSPF-TE only. Extensions [I-D.giacalone-ospf-te-express-path] proposes to extend OSPF-TE
support delay, delay variance, loss, residual bandwidth, and only. Extensions support delay, delay variance, loss, residual
available bandwidth. No extensions to RSVP-TE are proposed. bandwidth, and available bandwidth. No extensions to RSVP-TE are
This draft is intended to proceed in the CCAMP WG. It is proposed. This draft is intended to proceed in the CCAMP WG. It
currently and individual submission. The 02 version will expire is currently and individual submission which has expired.
in March 2012.
A possible course of action may be to combine these two drafts. The A possible course of action may be to combine these two drafts. The
delay variance, loss, residual bandwidth, and available bandwidth delay variance, loss, residual bandwidth, and available bandwidth
extensions are particular prone to network instability. The question extensions are particular prone to network instability. The question
as to whether queuing delay and delay variation should be considered, as to whether queuing delay and delay variation should be considered,
and if so for which diffserv Per-Hop Service Class (PSC) is not and if so for which diffserv Per-Hop Service Class (PSC) is not
addressed. addressed.
Note to co-authors: The ccamp-latency-te-metric draft refers to Note to co-authors: The ccamp-latency-te-metric draft refers to
[I-D.ietf-rtgwg-cl-requirement] and is well matched to those [I-D.ietf-rtgwg-cl-requirement] and is well matched to those
skipping to change at page 26, line 4 skipping to change at page 28, line 40
group is given an interface identification like the bundle itself. group is given an interface identification like the bundle itself.
The extensions could also be further extended to support The extensions could also be further extended to support
specification of the all-ones component link in the ERO or RRO. specification of the all-ones component link in the ERO or RRO.
[I-D.ietf-mpls-explicit-resource-control-bundle] does not provide a [I-D.ietf-mpls-explicit-resource-control-bundle] does not provide a
means to advertise the link bundle components. It is not certain how means to advertise the link bundle components. It is not certain how
the ingress LSR would determine the set of link bundle component the ingress LSR would determine the set of link bundle component
links available for a given link bundle. links available for a given link bundle.
[I-D.ospf-cc-stlv] provides a baseline draft for extending link [I-D.ospf-cc-stlv] provides a baseline draft for extending link
bundling to advertise components. A new component TVL (C-TLV) is bundling to advertise components. A new component TLV (C-TLV) is
proposed, which must reference a Composite Link Link TLV. proposed, which must reference a Composite Link Link TLV.
[I-D.ospf-cc-stlv] is intended for the OSPF WG and submitted for the [I-D.ospf-cc-stlv] is intended for the OSPF WG and submitted for the
"Experimental" track. The 00 version expired in February 2012. "Experimental" track. The 00 version expired in February 2012.
6.3. Fat PW and Entropy Labels 6.3. Pseudowire Flow and MPLS Entropy Labels
Two documents provide a means to add entropy for the purpose of Two documents provide a means to add entropy for the purpose of
improving load balance. MPLS encapsulation can bury information that improving load balance. MPLS encapsulation can bury information that
is needed to identify microflows. These two documents allow a is needed to identify microflows. These two documents allow a
pseudowire ingress and LSP ingress respectively to add a label solely pseudowire ingress and LSP ingress respectively to add a label solely
for the purpose of providing a finer granularity of microflow groups. for the purpose of providing a finer granularity of microflow groups.
[RFC6391] allows pseudowires which carry a large volume of traffic, [RFC6391] allows pseudowires which carry a large volume of traffic,
where microflows can be identified to be load balanced across where microflows can be identified to be load balanced across
multiple members of an Ethernet LAG or an MPLS link bundle. This is multiple members of an Ethernet LAG or an MPLS link bundle. This is
accomplished by adding a flow label below the pseudowire label in the accomplished by adding a flow label below the pseudowire label in the
MPLS label stack. For this to be effective the link bundle load MPLS label stack. For this to be effective the link bundle load
balance must make use of the label stack up to and including this balance must make use of the label stack up to and including this
flow label. flow label.
[I-D.ietf-mpls-entropy-label] provides a means for a LER to put an [I-D.ietf-mpls-entropy-label] provides a means for a LER to put an
additional label known as an entropy label on the MPLS label stack. additional label known as an entropy label on the MPLS label stack.
As defined, only the LER can add the entropy label. Only the LER can add the entropy label. The LER of a PSC LSP would
have to add a entropy label for contained LSPs for which it is a
midpoint LSR. LSP packet ordering requirements can be passed to an
LSP midpoint using the extensions in
[I-D.villamizar-mpls-tp-multipath-te-extn].
Core LSR acting as LER for aggregated LSP can add entropy labels Core LSR acting as LER for aggregated LSP can add entropy labels
based on deep packet inspection and place an entropy label indicator based on deep packet inspection and place an entropy label indicator
(ELI) and entropy label (EL) just below the label being acted on. (ELI) and entropy label (EL) just below the label being acted on.
This would be helpful in situations where the label stack depth to This would be helpful in situations where the label stack depth to
which load distribution can operate is limited by implementation or which load distribution can operate is limited by implementation or
is limited for other reasons such as carrying both MPLS-TP and MPLS is limited for other reasons such as carrying both MPLS-TP and MPLS
with entropy labels within the same hierarchical LSP. with entropy labels within the same hierarchical LSP.
6.4. Multipath Extensions 6.4. Multipath Extensions
The multipath extensions drafts address one aspect of Composite Link. The multipath extensions drafts address the issue of accommodating
These drafts deal with the issue of accommodating LSP which have LSP which have strict packet ordering constraints in a network
strict packet ordering constraints in a network containing multipath. containing multipath. MPLS-TP has become the one important instance
MPLS-TP has become the one important instance of LSP with strict of LSP with strict packet ordering constraints and has driven this
packet ordering constraints and has driven this work. work.
[I-D.villamizar-mpls-tp-multipath] outlines requirements and gives a [I-D.villamizar-mpls-tp-multipath] proposed to use MPLS Entropy Label
number of options for dealing with the apparent incompatibility of [I-D.ietf-mpls-entropy-label] to allow MPLS-TP to be carried within
MPLS-TP and multipath. A preferred option is described. MPLS LSP that make use of multipath. Limitations of this approach in
the absence of protocol extensions is discussed.
[I-D.villamizar-mpls-tp-multipath-te-extn] provides protocol [I-D.villamizar-mpls-tp-multipath-te-extn] provides protocol
extensions needed to implement the preferred option described in extensions needed to overcome the limitations in the absence of
protocol extensions is discussed in
[I-D.villamizar-mpls-tp-multipath]. [I-D.villamizar-mpls-tp-multipath].
Other issues pertaining to multipath are also addressed. Means to Other issues pertaining to multipath are also addressed in
advertise the largest microflow supportable are defined. Means to [I-D.villamizar-mpls-tp-multipath-te-extn]. Means to advertise the
indicate the largest expected microflow within an LSP are defined. largest microflow supportable are defined. Means to indicate the
Issues related to hierarchy are addressed. largest expected microflow within an LSP are defined. Issues related
to hierarchy are addressed.
7. Required Protocol Extensions and Mechanisms 7. Required Protocol Extensions and Mechanisms
Prior sections have reviewed key characteristics, architecture Prior sections have reviewed key characteristics, architecture
tradeoffs, new challenges, existing mechanisms, and relevant tradeoffs, new challenges, existing mechanisms, and relevant
mechanisms proposed in existing new documents. mechanisms proposed in existing new documents.
This section first summarizes and groups requirements. A set of This section first summarizes and groups requirements specified in
[I-D.ietf-rtgwg-cl-requirement] (see Section 7.1). A set of
documents coverage groupings are proposed with existing works-in- documents coverage groupings are proposed with existing works-in-
progress noted where applicable. The set of extensions are then progress noted where applicable (see Section 7.2). The set of
grouped by protocol affected as a convenience to implementors. extensions are then grouped by protocol affected as a convenience to
implementors (see (see Section 7.3).
7.1. Brief Review of Requirements 7.1. Brief Review of Requirements
The following list provides a categorization of requirements The following list provides a categorization of requirements
specified in [I-D.ietf-rtgwg-cl-requirement] along with a short specified in [I-D.ietf-rtgwg-cl-requirement] along with a short
phrase indication what topic the requirement covers. phrase indication what topic the requirement covers.
routing information aggregation routing information aggregation
FR#1 (routing summarization), FR#20 (composite link may be a FR#1 (routing summarization), FR#20 (composite link may be a
component of another composite link) component of another composite link)
skipping to change at page 28, line 33 skipping to change at page 31, line 27
and de-activation) and de-activation)
path determination, connectivity verification path determination, connectivity verification
MR#4 (path trace), MR#5 (connectivity verification) MR#4 (path trace), MR#5 (connectivity verification)
The above list is not intended as a substitute for The above list is not intended as a substitute for
[I-D.ietf-rtgwg-cl-requirement], but rather as a concise grouping and [I-D.ietf-rtgwg-cl-requirement], but rather as a concise grouping and
reminder or requirements to serve as a means of more easily reminder or requirements to serve as a means of more easily
determining requirements coverage of a set of protocol documents. determining requirements coverage of a set of protocol documents.
7.2. Required Document Coverage 7.2. Proposed Document Coverage
The primary areas where additional protocol extensions and mechanisms The primary areas where additional protocol extensions and mechanisms
are required include the topics described in the following are required include the topics described in the following
subsections. subsections.
There are candidate documents for a subset of the topics below. This There are candidate documents for a subset of the topics below. This
grouping of topics does not require that each topic be addressed by a grouping of topics does not require that each topic be addressed by a
separate document. In some cases, a document may cover multiple separate document. In some cases, a document may cover multiple
topics, or a specific topic may be addressed as applicable in topics, or a specific topic may be addressed as applicable in
multiple documents. multiple documents.
skipping to change at page 29, line 50 skipping to change at page 32, line 42
migration", and "general network management" requirements must also migration", and "general network management" requirements must also
be considered. be considered.
7.2.3. Path Selection and Admission Control 7.2.3. Path Selection and Admission Control
Path selection and admission control changes must be documented in Path selection and admission control changes must be documented in
each document that proposes a protocol extension that advertises a each document that proposes a protocol extension that advertises a
new capability or parameter that must be supported by changes in path new capability or parameter that must be supported by changes in path
selection and admission control. selection and admission control.
It would also be helpful to have an informational document which
covers path selection and admission control issues in detail and
briefly summarizes and references the set of documents which propose
extensions. This document could be advanced in parallel with the
protocol extensions.
The primary focus of this document, among the sets of requirements The primary focus of this document, among the sets of requirements
listed in Section 7.1 are the "load distribution, stability, minimal listed in Section 7.1 are the "load distribution, stability, minimal
disruption" and "admission control, preemption, traffic engineering" disruption" and "admission control, preemption, traffic engineering"
sets of requirements. The "restoration speed" and "path sets of requirements. The "restoration speed" and "path
determination, connectivity verification" requirements must also be determination, connectivity verification" requirements must also be
considered. The "backward compatibility and migration", and "general considered. The "backward compatibility and migration", and "general
network management" requirements must also be considered. network management" requirements must also be considered.
7.2.4. Dynamic Multipath Balance 7.2.4. Dynamic Multipath Balance
FR#11 explicitly calls for dynamic load balancing similar to existing FR#11 explicitly calls for dynamic placement of flows. Load
adaptive multipath. In implementations where flow identification balancing similar to existing dynamic multipath would satisfy this
uses a coarse granularity, the adjustments would have to be equally requirement. In implementations where flow identification uses a
coarse, in the worst case moving entire LSP. The impact of flow coarse granularity, the adjustments would have to be equally coarse,
identification granularity and potential adaptive multipath in the worst case moving entire LSP. The impact of flow
approaches may need to be documented in greater detail than provided identification granularity and potential dynamic multipath approaches
here. may need to be documented in greater detail than provided here.
The primary focus of this document, among the sets of requirements The primary focus of this document, among the sets of requirements
listed in Section 7.1 are the "restoration speed" and the "load listed in Section 7.1 are the "restoration speed" and the "load
distribution, stability, minimal disruption" sets of requirements. distribution, stability, minimal disruption" sets of requirements.
The "path determination, connectivity verification" requirements must The "path determination, connectivity verification" requirements must
also be considered. The "backward compatibility and migration", and also be considered. The "backward compatibility and migration", and
"general network management" requirements must also be considered. "general network management" requirements must also be considered.
7.2.5. Frequency of Load Balance 7.2.5. Frequency of Load Balance
skipping to change at page 31, line 13 skipping to change at page 34, line 11
applicable. applicable.
The primary focus of this document, among the sets of requirements The primary focus of this document, among the sets of requirements
listed in Section 7.1 is the "restoration speed" set of requirements. listed in Section 7.1 is the "restoration speed" set of requirements.
The "backward compatibility and migration" and "general network The "backward compatibility and migration" and "general network
management" requirements must also be considered. management" requirements must also be considered.
7.2.7. Packet Ordering Requirements 7.2.7. Packet Ordering Requirements
A document is needed to define extensions supporting various packet A document is needed to define extensions supporting various packet
ordering requirements, ranging from requirements to preservce ordering requirements, ranging from requirements to preserve
microflow ordering only, to requirements to preservce full LSP microflow ordering only, to requirements to preserve full LSP
ordering (as in MPLS-TP). This is covered by ordering (as in MPLS-TP). This is covered by
[I-D.villamizar-mpls-tp-multipath] and [I-D.villamizar-mpls-tp-multipath] and
[I-D.villamizar-mpls-tp-multipath-te-extn]. [I-D.villamizar-mpls-tp-multipath-te-extn].
The primary focus of this document, among the sets of requirements The primary focus of this document, among the sets of requirements
listed in Section 7.1 are the "admission control, preemption, traffic listed in Section 7.1 are the "admission control, preemption, traffic
engineering" and the "path determination, connectivity verification" engineering" and the "path determination, connectivity verification"
sets of requirements. The "backward compatibility and migration" and sets of requirements. The "backward compatibility and migration" and
"general network management" requirements must also be considered. "general network management" requirements must also be considered.
skipping to change at page 31, line 42 skipping to change at page 34, line 40
compatibility with older hardware needs to be accommodated. compatibility with older hardware needs to be accommodated.
The primary focus of this document, among the sets of requirements The primary focus of this document, among the sets of requirements
listed in Section 7.1 is the "load distribution, stability, minimal listed in Section 7.1 is the "load distribution, stability, minimal
disruption" set of requirements. disruption" set of requirements.
7.2.9. Path Symmetry 7.2.9. Path Symmetry
Protocol extensions are needed to support dynamic load balance as Protocol extensions are needed to support dynamic load balance as
called for to meet FR#22 (path symmetry) and to meet FR#11 (dynamic called for to meet FR#22 (path symmetry) and to meet FR#11 (dynamic
placement of flows). Currently path symmetry can only be supported placement of flows).
in link bundling if the path is pinned. When a flow is moved both
ingress and egress must make the move as close to simultaneously as Currently path symmetry can only be supported in link bundling if the
possible to satisfy FR#22 and FR#12 (minimally disruptive load path is pinned. When a flow is moved both ingress and egress must
rebalance). If a group of flows are identified using a hash, then make the move as close to simultaneously as possible to satisfy FR#22
the hash must be identical on the pair of LSR at the endpoint, using and FR#12 (minimally disruptive load rebalance). There is currently
the same hash seed and with one side swapping source and destination. no protocol to coordinate this move.
If the label stack is used, then either the entire label stack must
be a special case flow identification, since the set of labels in If a group of flows are identified using a hash, then the hash must
either direction are not correlated, or the two LSR must conspire to be identical on the pair of LSR at the endpoint, using the same hash
use the same flow identifier. For example, using a common entropy seed and with one side swapping source and destination. If the label
label value, and using only the entropy label in the flow stack is used, then either the entire label stack must be a special
identification would satisfy this requirement. case flow identification, since the set of labels in either direction
are not correlated, or the two LSR must conspire to use the same flow
identifier. For example, using a common entropy label value, and
using only the entropy label in the flow identification would satisfy
the forwarding requirement. There is no protocol to indicate special
treatment of a label stack within a hierarchical LSP. Adding such a
extension may add significant complexity and ultimately may prove
unscalable.
The primary focus of this document, among the sets of requirements The primary focus of this document, among the sets of requirements
listed in Section 7.1 are the "load distribution, stability, minimal listed in Section 7.1 are the "load distribution, stability, minimal
disruption" and the "admission control, preemption, traffic disruption" and the "admission control, preemption, traffic
engineering" sets of requirements. The "backward compatibility and engineering" sets of requirements. The "backward compatibility and
migration" and "general network management" requirements must also be migration" and "general network management" requirements must also be
considered. Path symetry simplifies support for the "path considered. Path symmetry simplifies support for the "path
determination, connectivity verification" set of requirements, but determination, connectivity verification" set of requirements, but
with significant complexity added elsewhere. with significant complexity added elsewhere.
7.2.10. Performance, Scalability, and Stability 7.2.10. Performance, Scalability, and Stability
A separate document providing analysis of performance, scalability, A separate document providing analysis of performance, scalability,
and stability impacts of changes may be needed. The topic of traffic and stability impacts of changes may be needed. The topic of traffic
adjustment oscillation must also be covered. If sufficient coverage adjustment oscillation must also be covered. If sufficient coverage
is provided in each document covering a protocol extension, a is provided in each document covering a protocol extension, a
separate document would not be needed. separate document would not be needed.
skipping to change at page 32, line 35 skipping to change at page 35, line 41
listed in Section 7.1 is the "restoration speed" set of requirements. listed in Section 7.1 is the "restoration speed" set of requirements.
This is not a simple topic and not a topic that is well served by This is not a simple topic and not a topic that is well served by
scattering it over multiple documents, therefore it may be best to scattering it over multiple documents, therefore it may be best to
put this in a separate document and put citations in documents called put this in a separate document and put citations in documents called
for in Section 7.2.1, Section 7.2.2, Section 7.2.3, Section 7.2.9, for in Section 7.2.1, Section 7.2.2, Section 7.2.3, Section 7.2.9,
Section 7.2.11, Section 7.2.12, Section 7.2.13, and Section 7.2.14. Section 7.2.11, Section 7.2.12, Section 7.2.13, and Section 7.2.14.
Citation may also be helpful in Section 7.2.4, and Section 7.2.5. Citation may also be helpful in Section 7.2.4, and Section 7.2.5.
7.2.11. IP and LDP Traffic 7.2.11. IP and LDP Traffic
A document is needed to define the use of measurements native IP and A document is needed to define the use of measurements of native IP
native LDP traffic levels to reduce link advertised bandwidth and native LDP traffic levels which are then used to reduce link
amounts. advertised bandwidth amounts.
The primary focus of this document, among the sets of requirements The primary focus of this document, among the sets of requirements
listed in Section 7.1 are the "load distribution, stability, minimal listed in Section 7.1 are the "load distribution, stability, minimal
disruption" and the "admission control, preemption, traffic disruption" and the "admission control, preemption, traffic
engineering" set of requirements. The "path determination, engineering" set of requirements. The "path determination,
connectivity verification" must also be considered. The "backward connectivity verification" must also be considered. The "backward
compatibility and migration" and "general network management" compatibility and migration" and "general network management"
requirements must also be considered. requirements must also be considered.
7.2.12. LDP Extensions 7.2.12. LDP Extensions
skipping to change at page 33, line 16 skipping to change at page 36, line 22
engineering capability. engineering capability.
The primary focus of this document, among the sets of requirements The primary focus of this document, among the sets of requirements
listed in Section 7.1 is the "admission control, preemption, traffic listed in Section 7.1 is the "admission control, preemption, traffic
engineering" set of requirements. The "backward compatibility and engineering" set of requirements. The "backward compatibility and
migration" and "general network management" requirements must also be migration" and "general network management" requirements must also be
considered. considered.
7.2.13. Pseudowire Extensions 7.2.13. Pseudowire Extensions
PW extensions such as signaling a bound on microflow size and PW Pseudowire (PW) extensions such as signaling a bound on microflow
requirements would provide useful information. size and signaling requirements specific to PW would provide useful
information. This information can be carried in the PW LDP signaling
[RFC3985] and the the PW requirements could then be used in a
containing LSP.
The primary focus of this document, among the sets of requirements The primary focus of this document, among the sets of requirements
listed in Section 7.1 is the "admission control, preemption, traffic listed in Section 7.1 is the "admission control, preemption, traffic
engineering" set of requirements. The "backward compatibility and engineering" set of requirements. The "backward compatibility and
migration" and "general network management" requirements must also be migration" and "general network management" requirements must also be
considered. considered.
7.2.14. Multi-Domain Composite Link 7.2.14. Multi-Domain Composite Link
DR#5 calls for Composite Link to span multiple network topologies. DR#5 calls for Composite Link to span multiple network topologies.
skipping to change at page 33, line 46 skipping to change at page 37, line 6
The authors and/or the WG may need to discuss this. DR#5 mandates The authors and/or the WG may need to discuss this. DR#5 mandates
that IGP-TE extension cannot be used. This would disallow the use of that IGP-TE extension cannot be used. This would disallow the use of
[RFC5316] or [RFC5392] in conjunction with [RFC5151]. [RFC5316] or [RFC5392] in conjunction with [RFC5151].
The primary focus of this document, among the sets of requirements The primary focus of this document, among the sets of requirements
listed in Section 7.1 are "single vs multiple domain" and "admission listed in Section 7.1 are "single vs multiple domain" and "admission
control, preemption, traffic engineering". The "routing information control, preemption, traffic engineering". The "routing information
aggregation" and "load distribution, stability, minimal disruption" aggregation" and "load distribution, stability, minimal disruption"
requirements need attention due to their use of the IGP in single requirements need attention due to their use of the IGP in single
domain Composite Link. Other requirements such as "delay and delay domain Composite Link. Other requirements such as "delay and delay
variation", can more easily be accomodated by carrying metrics within variation", can more easily be accommodated by carrying metrics
BGP. The "path determination, connectivity verification" within BGP. The "path determination, connectivity verification"
requirements need attention due to requirements to restrict requirements need attention due to requirements to restrict
disclosure of topology information across domains in multi-domain disclosure of topology information across domains in multi-domain
deployments. The "backward compatibility and migration" and "general deployments. The "backward compatibility and migration" and "general
network management" requirements must also be considered. network management" requirements must also be considered.
7.3. Open Issues Regarding Requirements 7.3. Framework Requirement Coverage by Protocol
Note to co-authors: This section needs to be reduced to an empty
section and then removed.
The following topics in the requirements document are not addressed.
Since they are explicitly mentioned in the requirements document some
mention of how they are supported is needed, even if to say nother
needed to be done. If we conclude any particular topic is
irrelevant, maybe the topic should be removed from the requirement
document. At that point we could add the management requirements
that have come up and were missed.
1. L3VPN RFC 4364, RFC 4797,L2VPN RFC 4664, VPWS, VPLS RFC 4761, RFC
4762 and VPMS VPMS Framework
(draft-ietf-l2vpn-vpms-frmwk-requirements). It is not clear what
additional Composite Link requirements these references imply, if
any. If no additional requirements are implied, then these
references are considered to be informational only.
2. Migration may not be adequately covered in Section 4.1.5. It
might also be necessary to say more here on performance,
scalability, and stability as it related to migration. Comments
on this from co-authors or the WG?
3. We may need a performance section in this document to
specifically address #DR6 (fast convergence), and #DR7 (fast
worst case failure convergence), though we do already have
scalability discussion. The performance section would have to
say "no worse than before, except were there was no alternative
to make it very slightly worse" (in a bit more detail than that).
It would also have to better define the nature of the performance
criteria.
7.4. Framework Requirement Coverage by Protocol
As an aid to implementors, this section summarizes requirement As an aid to implementors, this section summarizes requirement
coverage listed in Section 7.2 by protocol or LSR functionality coverage listed in Section 7.2 by protocol or LSR functionality
affected. affected.
Some documentation may be purely informational, proposing no changes Some documentation may be purely informational, proposing no changes
and proposing usage at most. This includes Section 7.2.3, and proposing usage at most. This includes Section 7.2.3,
Section 7.2.8, Section 7.2.10, and Section 7.2.14. Section 7.2.8, Section 7.2.10, and Section 7.2.14.
Section 7.2.9 may require a new protocol. Section 7.2.9 may require a new protocol.
7.4.1. OSPF-TE and ISIS-TE Protocol Extensions 7.3.1. OSPF-TE and ISIS-TE Protocol Extensions
Many of the changes listed in Section 7.2 require IGP-TE changes, Many of the changes listed in Section 7.2 require IGP-TE changes,
though most are small extensions to provide additional information. though most are small extensions to provide additional information.
This set includes Section 7.2.1, Section 7.2.2, Section 7.2.5, This set includes Section 7.2.1, Section 7.2.2, Section 7.2.5,
Section 7.2.6, and Section 7.2.7. An adjustment to existing Section 7.2.6, and Section 7.2.7. An adjustment to existing
advertised parameters is suggested in Section 7.2.11. advertised parameters is suggested in Section 7.2.11.
7.4.2. PW Protocol Extensions 7.3.2. PW Protocol Extensions
The only suggestion of pseudowire (PW) extensions is in The only suggestion of pseudowire (PW) extensions is in
Section 7.2.13. Section 7.2.13.
7.4.3. LDP Protocol Extensions 7.3.3. LDP Protocol Extensions
Potential LDP extensions are described in Section 7.2.12. Potential LDP extensions are described in Section 7.2.12.
7.4.4. RSVP-TE Protocol Extensions 7.3.4. RSVP-TE Protocol Extensions
RSVP-TE protocol extensions are called for in Section 7.2.1, RSVP-TE protocol extensions are called for in Section 7.2.1,
Section 7.2.5, Section 7.2.7, and Section 7.2.9. Section 7.2.5, Section 7.2.7, and Section 7.2.9.
7.4.5. RSVP-TE Path Selection Changes 7.3.5. RSVP-TE Path Selection Changes
Section 7.2.3 calls for path selection to be addressed in individual Section 7.2.3 calls for path selection to be addressed in individual
documents that require change. These changes would include those documents that require change. These changes would include those
proposed in Section 7.2.1, Section 7.2.2, Section 7.2.5, and proposed in Section 7.2.1, Section 7.2.2, Section 7.2.5, and
Section 7.2.7. Section 7.2.7.
7.4.6. RSVP-TE Admission Control and Preemption 7.3.6. RSVP-TE Admission Control and Preemption
When a change is needed to path selection, a corresponding change is When a change is needed to path selection, a corresponding change is
needed in admission control. The same set of sections applies: needed in admission control. The same set of sections applies:
Section 7.2.1, Section 7.2.2, Section 7.2.5, and Section 7.2.7. Some Section 7.2.1, Section 7.2.2, Section 7.2.5, and Section 7.2.7. Some
resource changes such as a link delay change might trigger resource changes such as a link delay change might trigger
preemption. The rules of preemption remain unchanged, still based on preemption. The rules of preemption remain unchanged, still based on
holding priority. holding priority.
7.4.7. Flow Identification and Traffic Balance 7.3.7. Flow Identification and Traffic Balance
The following describe either the state of the art in flow The following describe either the state of the art in flow
identification and traffic balance or propose changes: Section 7.2.4, identification and traffic balance or propose changes: Section 7.2.4,
Section 7.2.5, Section 7.2.7, and Section 7.2.8. Section 7.2.5, Section 7.2.7, and Section 7.2.8.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This is a framework document and therefore does not specify protocol
extensions. This memo includes no request to IANA.
9. Security Considerations 9. Security Considerations
The security considerations for MPLS/GMPLS and for MPLS-TP are The security considerations for MPLS/GMPLS and for MPLS-TP are
documented in [RFC5920] and [I-D.ietf-mpls-tp-security-framework]. documented in [RFC5920] and [I-D.ietf-mpls-tp-security-framework].
The types protocol extensions proposed in this framework document The types protocol extensions proposed in this framework document
provide additional information about links, forwarding adjacencies, provide additional information about links, forwarding adjacencies,
and LSP requirements. The protocol semantics changes described in and LSP requirements. The protocol semantics changes described in
this framework document propose additional LSP constraints applied at this framework document propose additional LSP constraints applied at
skipping to change at page 37, line 39 skipping to change at page 40, line 16
J., and S. Amante, "Flow-Aware Transport of Pseudowires J., and S. Amante, "Flow-Aware Transport of Pseudowires
over an MPLS Packet Switched Network", RFC 6391, over an MPLS Packet Switched Network", RFC 6391,
November 2011. November 2011.
11.2. Informative References 11.2. Informative References
[DBP] Bertsekas, D., "Dynamic Behavior of Shortest Path Routing [DBP] Bertsekas, D., "Dynamic Behavior of Shortest Path Routing
Algorithms for Communication Networks", IEEE Trans. Auto. Algorithms for Communication Networks", IEEE Trans. Auto.
Control 1982. Control 1982.
[I-D.giacalone-ospf-te-express-path]
Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Express Path",
draft-giacalone-ospf-te-express-path-02 (work in
progress), September 2011.
[I-D.ietf-mpls-entropy-label] [I-D.ietf-mpls-entropy-label]
Kompella, K., Drake, J., Amante, S., Henderickx, W., and Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
draft-ietf-mpls-entropy-label-04 (work in progress), draft-ietf-mpls-entropy-label-06 (work in progress),
July 2012. September 2012.
[I-D.ietf-mpls-explicit-resource-control-bundle] [I-D.ietf-mpls-explicit-resource-control-bundle]
Zamfir, A., Ali, Z., and P. Dimitri, "Component Link Zamfir, A., Ali, Z., and P. Dimitri, "Component Link
Recording and Resource Control for TE Links", Recording and Resource Control for TE Links",
draft-ietf-mpls-explicit-resource-control-bundle-10 (work draft-ietf-mpls-explicit-resource-control-bundle-10 (work
in progress), April 2011. in progress), April 2011.
[I-D.ietf-mpls-tp-security-framework] [I-D.ietf-mpls-tp-security-framework]
Fang, L., Niven-Jenkins, B., Mansfield, S., and R. Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
Graveman, "MPLS-TP Security Framework", Graveman, "MPLS-TP Security Framework",
draft-ietf-mpls-tp-security-framework-04 (work in draft-ietf-mpls-tp-security-framework-04 (work in
progress), July 2012. progress), July 2012.
[I-D.ietf-rtgwg-cl-requirement] [I-D.ietf-rtgwg-cl-requirement]
Villamizar, C., McDysan, D., Ning, S., Malis, A., and L. Villamizar, C., McDysan, D., Ning, S., Malis, A., and L.
Yong, "Requirements for MPLS Over a Composite Link", Yong, "Requirements for MPLS Over a Composite Link",
draft-ietf-rtgwg-cl-requirement-07 (work in progress), draft-ietf-rtgwg-cl-requirement-08 (work in progress),
June 2012. August 2012.
[I-D.ietf-rtgwg-cl-use-cases] [I-D.ietf-rtgwg-cl-use-cases]
Ning, S., Malis, A., McDysan, D., Yong, L., and C. Ning, S., Malis, A., McDysan, D., Yong, L., and C.
Villamizar, "Composite Link Use Cases and Design Villamizar, "Composite Link Use Cases and Design
Considerations", draft-ietf-rtgwg-cl-use-cases-01 (work in Considerations", draft-ietf-rtgwg-cl-use-cases-01 (work in
progress), August 2012. progress), August 2012.
[I-D.kompella-mpls-rsvp-ecmp] [I-D.kompella-mpls-rsvp-ecmp]
Kompella, K., "Multi-path Label Switched Paths Signaled Kompella, K., "Multi-path Label Switched Paths Signaled
Using RSVP-TE", draft-kompella-mpls-rsvp-ecmp-01 (work in Using RSVP-TE", draft-kompella-mpls-rsvp-ecmp-01 (work in
skipping to change at page 39, line 28 skipping to change at page 42, line 10
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004. (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005. Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006. Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, April 2006.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128, Cost Multipath Treatment in MPLS Networks", BCP 128,
RFC 4928, June 2007. RFC 4928, June 2007.
[RFC5151] Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain [RFC5151] Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain
MPLS and GMPLS Traffic Engineering -- Resource Reservation MPLS and GMPLS Traffic Engineering -- Resource Reservation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions",
 End of changes. 101 change blocks. 
347 lines changed or deleted 487 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/