%% You should probably cite draft-ali-ccamp-rc-objective-function-metric-bound-05 instead of this revision. @techreport{ali-ccamp-rc-objective-function-metric-bound-03, number = {draft-ali-ccamp-rc-objective-function-metric-bound-03}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-ali-ccamp-rc-objective-function-metric-bound/03/}, author = {Zafar Ali and George Swallow and Clarence Filsfils and Luyuan Fang and Kenji Kumaki and Ruediger Kunze and Daniele Ceccarelli}, title = {{Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for signaling Objective Function and Metric Bound}}, pagetotal = 13, year = 2013, month = jul, day = 15, abstract = {In particular networks such as those used by financial institutions, network performance criteria such as latency are becoming as critical to data path selection. However cost is still an important consideration. This leads to a situation where path calculation involves multiple metrics and more complex objective functions. When using GMPLS control plane, there are many scenarios in which a node may need to request a remote node to perform path computation or expansion, like for example multi-domain LSP setup, Generalized Multi-Protocol Label Switching (GMPLS) User-Network Interface (UNI) or simply the utilization of a loose ERO in intra domain signaling. In such cases, the node requesting for the setup of an LSP needs to convey the required objective function to the remote node, to enable it to perform route computation in the desired fashion. Similarly, there are cases the ingress needs to indicate a TE metric bound for a loose segment that is expanded by a remote node. This document defines extensions to the RSVP-TE Protocol to allow an ingress node to request the required objective function for the route computation, as well as a metric bound to influence route computation decisions at a remote node(s).}, }