Performance-based Path Selection for Explicitly Routed LSPs using TE Metric Extensions
draft-ietf-teas-te-express-path-01
TEAS Working Group A. Atlas
Internet-Draft J. Drake
Intended status: Informational Juniper Networks
Expires: September 27, 2015 S. Giacalone
Thomson Reuters
D. Ward
S. Previdi
C. Filsfils
Cisco Systems
March 26, 2015
Performance-based Path Selection for Explicitly Routed LSPs using TE
Metric Extensions
draft-ietf-teas-te-express-path-01
Abstract
In certain networks, it is critical to consider network performance
criteria when selecting the path for an explicitly routed RSVP-TE
LSP. Such performance criteria can include latency, jitter, and loss
or other indications such as the conformance to link performance
objectives and non-RSVP TE traffic load. This specification uses
network performance data, such as is advertised via the OSPF and ISIS
TE metric extensions (defined outside the scope of this document) to
perform such path selections.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 27, 2015.
Atlas, et al. Expires September 27, 2015 [Page 1]
Internet-Draft Path Selection with TE Metric Extensions March 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Basic Requirements . . . . . . . . . . . . . . . . . . . 4
1.2. Oscillation and Stability Considerations . . . . . . . . 4
2. Using Performance Data Constraints . . . . . . . . . . . . . 5
2.1. End-to-End Constraints . . . . . . . . . . . . . . . . . 5
2.2. Link Constraints . . . . . . . . . . . . . . . . . . . . 6
2.3. Links out of compliance with Link Performance Objectives 6
2.3.1. Use of Anomalous Links for New Paths . . . . . . . . 7
2.3.2. Links entering the Anomalous State . . . . . . . . . 7
2.3.3. Links leaving the Anomalous State . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
In certain networks, such as financial information networks, network
performance information is becoming as critical to data path
selection as other existing metrics. Network performance information
can be obtained via either the TE Metric Extensions in OSPF [RFC7471]
or ISIS [I-D.ietf-isis-te-metric-extensions] or via a management
system. As with other TE information flooded via OSPF or ISIS, the
TE metric extensions have a flooding scope limited to the local area
or level. This document describes how a path computation function,
whether in an ingress LSR or a PCE[RFC4655] , can use that
information for path selection for explicitly routed LSPs. The
selected path may be signaled via RSVP-TE [RFC3209] or simply used by
Show full document text