%% You should probably cite draft-ietf-ccamp-lsp-diversity instead of this I-D. @techreport{fedyk-ccamp-uni-extensions-01, number = {draft-fedyk-ccamp-uni-extensions-01}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-fedyk-ccamp-uni-extensions/01/}, author = {Don Fedyk and Dieter Beller and Lieven Levrau and Daniele Ceccarelli and Fatai Zhang and Yuji Tochio}, title = {{UNI Extensions for Diversity and Latency Support}}, pagetotal = 19, year = 2013, month = feb, day = 25, abstract = {This document builds on the GMPLS overlay model {[}RFC4208{]} and defines extensions to the GMPLS User-Network Interface (UNI) to support route diversity within the core network for sets of LSPs initiated by edge nodes. A particular example where route diversity within the core network is desired, are dual-homed edge nodes. The document also defines GMPLS UNI extensions to deal with latency requirements for edge node initiated LSPs. This document uses a VPN model that is based on the same premise as L1VPN framework {[}RFC4847{]} but may also be applied to other technologies. The extensions are applicable both to VPN and non VPN environments. These extensions move the UNI from basic connectivity to enhanced mode connectivity by including additional constraints while minimizing the exchange of CE to PE information. These extensions are applicable to the overlay extension service model. Route Diversity for customer LSPs are a common requirement applicable to L1VPNs. The UNI mechanisms described in this document are L1VPN compatible and can be applied to achieve diversity for sets of customer LSPs. The UNI extensions in support of latency constraints can also be applied to the extended overlay service model in order for the customer LSPs to meet certain latency requirements.}, }