Traffic Engineering Extensions to OSPF Version 3

Ishiguro, Kunihiro; Lindem, Acee; Davey, Alan; Manral, Vishwas

doi:10.17487/rfc5329

Cited by 58 publications

(14 citation statements)

References 5 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…The only difference is the TLV type, which is 35. The sub-TLV MUST only appear in Type 2 Link TLVs (Multi-access) of Traffic Engineer LSAs (OSPF2) or Intra-Area-TE-LSAs (OSPFv3) [RFC5329], and MUST appear at most once in such a Link TLV.…”

Section: Advertising Network-to-router Traffic Engineering (Te) Metricmentioning

confidence: 99%

OSPF Two-Part Metric

Wang¹,

Lindem²,

Zhang³

2016

View full text Add to dashboard Cite

Section: Advertising Network-to-router Traffic Engineering (Te) Metricmentioning

confidence: 99%

OSPF Two-Part Metric

Wang¹,

Lindem²,

Zhang³

2016

View full text Add to dashboard Cite

“…The extensions in this document build on the ones provided in OSPFv2 TE [RFC3630] and OSPFv3 TE [RFC5329].…”

Section: Te Metric Extensions To Ospf Tementioning

confidence: 99%

OSPF Traffic Engineering (TE) Metric Extensions

Giacalone¹,

Ward²,

Drake³

et al. 2015

View full text Add to dashboard Cite

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection.This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance.Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document.

show abstract

“…The Enhanced GMPLS Network supports the standard GMPLS signaling protocol, RSVP-TE [14][15][16][17][18][19][20][21], and routing protocol, OSPF [7][8][9][10][11][12][13], with enhancements to provide scheduled services as defined in Phase I [1] and refined in this project. These enhancements allow the user to specify a desired start time and duration for the LSP service, parameters that are not supported by the standard GMPLS protocols.…”

Section: Enhanced Gmpls Network Elementsmentioning

confidence: 99%

Final Report - Dynamic Path Scheduling through Extensions to Generalized Multiprotocol Label Switching (GMPLS)

Battou¹

2009

View full text Add to dashboard Cite

The major accomplishments of the project are the successful software implementation of the Phase I scheduling algorithms for GMPLS Label Switched Paths (LSPs) and the extension of the IETF Path Computation Element (PCE) Protocol to support scheduling extensions. In performing this work, we have demonstrated the theoretical work of Phase I, analyzed key issues, and made relevant extensions.Regarding the software implementation, we developed a proof of concept prototype as part of our Algorithm Evaluation System (AES). This implementation uses the Linux operating system to provide software portability and will be the foundation for our commercial software. To demonstrate proof of concept, we have implemented LSP scheduling algorithms to support two of the key GMPLS switching technologies (Lambda and Packet) and support both Fixed Path (FP) and Switched Path (SP) routing. We chose Lambda and Packet because we felt it was essential to include both circuit and packet switching technologies as well as to address alloptical switching in the study. As conceptualized in Phase I, the FP algorithms use a traditional approach where the LSP uses the same physical path for the entire service duration while the innovative SP algorithms allow the physical path to vary during the service duration.As part of this study, we have used the AES to conduct a performance analysis using metro size networks (up to 32 nodes) that showed that these algorithms are suitable for commercial implementation. Our results showed that the CPU time required to compute an LSP schedule was small compared to expected inter-arrival time between LSP requests. Also, when the network size increased from 7 to 15 to 32 nodes with 10, 26, and 56 TE links, the CPU processing time showed excellent scaling properties.When Fixed Path and Switched Path routing were compared, SP provided only modestly better performance with respect to LSP completion rate, service duration, path length, and start time deviation. In addition, the SP routing required somewhat more CPU time than the FP routing. However, when the allowable range for the start time is increased, the CPU time for SP increased less rapidly than FP such that the CPU processing times became comparable. Therefore, SP routing may scale better than FP routing.The Path Computation Element Working Group is a complementary working group to the GMPLS working group (CCAMP) in the IETF and is developing standards to discover, manage, and access elements that compute routes for GMPLS for LSPs. The algorithms used to compute the routes are not subject to standardization. Since the PCE supports only standard GMPLS LSPs, it does not support scheduled LSPs. Therefore, it is a natural extension of our Phase I work to introduce this enhancement into the PCE. In addition, the PCE adds another dimension to our product line because the PCE by itself may be a product with a standard interface.With the results of Phase II, we are now positioned to begin commercialization, Phase III. We will continue our ongoing fund raising and...

show abstract

Traffic Engineering Extensions to OSPF Version 3

Cited by 58 publications

References 5 publications

OSPF Two-Part Metric

OSPF Two-Part Metric

OSPF Traffic Engineering (TE) Metric Extensions

Final Report - Dynamic Path Scheduling through Extensions to Generalized Multiprotocol Label Switching (GMPLS)

Contact Info

Product

Resources

About