Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for signaling Objective Function and Metric Bound
draft-ali-ccamp-rc-objective-function-metric-bound-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Zafar Ali , George Swallow , Clarence Filsfils | ||
| Last updated | 2012-03-05 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ali-ccamp-rc-objective-function-metric-bound-00
quot; candidate paths. The draft also
defines a RSVP-TE protocol mechanism to allow an ingress node to
indicate TE metric bound(s) associated with the route expansion
request.
2. RSVP-TE signaling extensions
This section defines RSVP-TE signaling extensions required to
address the above-mentioned requirements. Two new ERO subobject
types, Objective Function (OF) and Metric, are defined for this
purpose. Their purpose is as follows.
. OF subobject conveys a set of one or more specific
optimization criteria that MUST be followed in expanding route
of a TE-LSP in MultiProtocol Label Switching (MPLS) and GMPLS
networks.
. Metric subobject indicates the bound on the path metric that
MUST NOT be exceeded for the loose segment to be considered as
acceptable by the ingress node.
The scope of the Metric and OF subobjects is the node performing
the expansion for loose ERO and the subsequent ERO subobject that
identifies an abstract node. The following subsection provides
the details.
2.1. Objective Function (OF) Subobject
A new ERO subobject type Objective Function (OF) is defined in
order for the ingress node to indicate the required objective
function on a loose hop. The ERO subobject type OF is optional.
It MAY be carried within an ERO object of RSVP-TE Path message.
The OF subobject has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | OF Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of OF subobject are defined as follows:
Ali, Swallow, Filsfils Expires September 2012 [Page 4]
ID draft-ali-ccamp-rc-objective-function-metric-bound-00.txt
L bit: The L bit SHOULD be set, so that the subobject
represents a loose hop in the explicit route.
Type: The Type is to be assigned by IANA (suggested value:
66).
Length: The Length contains the total length of the subobject
in bytes, including the Type field, the Length field and the
length of the optional TLV(s). When there is no optional TLV,
the Length is 4.
OF Code (1 byte): The identifier of the objective function.
The following OF code values are suggested. These values are to
be assigned by IANA.
* OF code value 0 is reserved.
* OF code value 1 (to be assigned by IANA) is for Minimum TE
Metric Cost Path (MTMCP) OF defined in this document. See
definition of MTMCP OF in the following.
* OF code value 2 (to be assigned by IANA) is for Minimum
Interior Gateway Protocol (IGP) Metric Cost Path (MIMCP)
OF defined in this document. See definition of MTMCP OF
in the following.
* OF code value 3 (to be assigned by IANA) is for Minimum
Load Path (MLP) OF as defined in [RFC5541].
* OF code value 4 (to be assigned by IANA) is for Maximum
Residual Bandwidth Path (MBP) OF as defined in [RFC5541].
* OF code value 5 (to be assigned by IANA) is for Minimize
Aggregate Bandwidth Consumption (MBC) OF as defined in
[RFC5541].
* OF code value 6 (to be assigned by IANA) is for Minimize
the Load of the most loaded Link (MLL) OF as defined in
[RFC5541].
* OF code value 7 is skipped (to keep the objective function
code values consistent between [RFC5541] and this draft.
* OF code value 8 (to be assigned by IANA) is for Minimum
Latency Path (MLP) OF defined in this document. See
definition of MLP OF in the following.
* OF code value 9 (to be assigned by IANA) is for Minimum
Latency Variation Path (MLVP) OF defined in this document.
See definition of MLVP OF in the following.
Ali, Swallow, Filsfils Expires September 2012 [Page 5]
ID draft-ali-ccamp-rc-objective-function-metric-bound-00.txt
Other objective functions may be defined in future.
Reserved (1 byte): This field MUST be set to zero on
transmission and MUST be ignored on receipt.
Optional TLVs may be defined in the future to encode
objective function parameters.
2.1.1. Minimum TE Metric Cost Path Objective Function
Minimum TE Metric Cost Path (MTMCP) OF is defined as an
Objective Function where a path is computed such that the sum of
the TE metric of the links along the path is minimized. In the
context of loose hop expansion, the ERO expanding node MUST try
to find a route such that the sum of the TE metric of the links
along the route is minimized.
2.1.2. Minimum IGP Metric Cost Path Objective Function
Minimum IGP Metric Cost Path (MIMCP) OF is defined as an
Objective Function where a path is computed such that the sum of
the IGP metric of the links along the path is minimized. In the
context of loose hop expansion, the ERO expanding node MUST try
to find a route such that the sum of the IGP metric of the links
along the route is minimized.
2.1.3. Minimum Latency Path Objective Function
Minimum Latency Path (MLP) OF is defined as an Objective
Function where a path is computed such that latency of the path
is minimized. In the context of loose hop expansion, the ERO
expanding node MUST try to find a route such that overall
latency of the loose hop is minimized.
2.1.4. Minimum Latency Variation Path Objective Function
Minimum Latency Variation Path (MLVP) OF is defined as an
Objective Function where a path is computed such that latency
variation in the path is minimized. In the context of loose hop
expansion, the ERO expanding node MUST try to find a route such
that overall latency variation of the loose hop is minimized.
Ali, Swallow, Filsfils Expires September 2012 [Page 6]
ID draft-ali-ccamp-rc-objective-function-metric-bound-00.txt
2.2. Metric subobject
The ERO subobject type Metric is optional. It MAY be carried
within an ERO object of RSVP-TE Path message. This subobject has
the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | metric-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the Metric subobject are defined as follows:
L bit: The L bit SHOULD be set, so that the subobject
represents a loose hop in the explicit route.
Type: The Type is to be assigned by IANA (suggested value:
67).
Length: The Length is 8.
Metric-type (8 bits): Specifies the metric type associated
with the partial route expended by the node processing the
loose ERO. The following values are currently defined:
* T=1: cumulative IGP cost
* T=2: cumulative TE cost
* T=3: Hop Counts
* T=4: Cumulative Latency
* T=5: Cumulative Latency Variation
Reserved: This field MUST be set to zero on transmission and
MUST be ignored on receipt.
Metric-bound (32 bits): The metric-bound indicates an upper
bound for the path metric that MUST NOT be exceeded for the ERO
expending node to consider the computed path as acceptable. The
metric bound is encoded in 32 bits using IEEE floating point
format as defined in [IEEE.754.1985]).
Ali, Swallow, Filsfils Expires September 2012 [Page 7]
ID draft-ali-ccamp-rc-objective-function-metric-bound-00.txt
2.3. Processing Rules for the OF Subobjects
The basic processing rules of an ERO are not altered. Please
refer to [RFC3209] for details.
The scope of the OF subobject is the previous ERO subobject that
identifies an abstract node, and the subsequent ERO subobject
that identifies an abstract node. Multiple OF subobjects may be
present between any pair of abstract nodes.
The following conditions SHOULD result in Path Error with error
code "Routing Problem" and error subcode "Bad EXPLICIT_ROUTE
object":
. If the first OF subobject is not preceded by a subobject
identifying the next hop.
. If the OF subobject follows a subobject that does not have
the L-bit set.
If the processing node does not understand the OF subobject, it
SHOULD sends a PathErr with the error code "Routing Error" and
error value of "Bad Explicit Route Object" toward the sender
[RFC3209].
If the processing node understands the OF subobject and the ERO
passes the above mentioned sanity check and any other sanity
checks associated with other ERO subobjects local to the node,
the node takes the following actions:
. If the node supports the requested OF(s), the node expands
the loose hop using the requested Objective Functions(s) as
minimization criterion (criteria) for computing the route to
the next abstract node. After processing, the OF subobjects
are removed from the ERO. The rest of the steps for the loose
ERO processing follow procedures outlined in [RFC3209].
. If the node understands the OF subobject but does not support
any or all of the requested OF(s), it SHOULD send a Path Error
with error code "Routing Problem" and a new error subcode
"Unsupported Objective Function". The error subcode
"Unsupported Objective Function" for Path Error code "Routing
Problem" is to be assigned by IANA (Suggested Value: 107).
Ali, Swallow, Filsfils Expires September 2012 [Page 8]
ID draft-ali-ccamp-rc-objective-function-metric-bound-00.txt
. If the node understands the OF subobject and supports all of
the requested OF(s) but cannot perform route computation with
all objective functions considered together as optimization
criteria for the path computation, it SHOULD send a Path Error
with error code "Routing Problem" and a new error subcode
"Objective Function too complex". The error subcode "Objective
Function too complex" for Path Error code "Routing Problem" is
to be assigned by IANA (Suggested Value: 108).
. If the objective function is supported but policy does not
permit applying it, the processing node SHOULD send a Path
Error with error code "Policy control failure" (value 2) and
subcode "objective function not allowed". The error subcode
"objective function not allowed" for Path Error code "Policy
control failure" is to be assigned by IANA (Suggested Value:
105).
2.4. Processing Rules for the Metric subobject
The basic processing rules of an ERO are not altered. Please
refer to [RFC3209] for details.
The scope of the Metric subobject is between the previous ERO
subobject that identifies an abstract node, and the subsequent
ERO subobject that identifies an abstract node. Multiple Metric
subobjects may be present between any pair of abstract nodes.
The following conditions SHOULD result in Path Error with error
code "Routing Problem" and error subcode "Bad EXPLICIT_ROUTE
object":
. If the first Metric subobject is not preceded by a subobject
identifying the next hop.
. If the Metric subobject follows a subobject that does not
have the L-bit set.
If the processing node does not understand the Metric subobject,
it SHOULD sends a PathErr with the error code "Routing Error" and
error value of "Bad Explicit Route Object" toward the sender
[RFC3209].
Ali, Swallow, Filsfils Expires September 2012 [Page 9]
ID draft-ali-ccamp-rc-objective-function-metric-bound-00.txt
If the processing node understands the Metric subobject and the
ERO passes the above mentioned sanity check and any other sanity
checks associated with other ERO subobjects local to the node,
the node takes the following actions:
. For all the Metric subobject(s), the node expands the loose
hop such that the requested metric bound(s) are met for the
route between the two abstract nodes in the ERO. After
processing, the Metric subobjects are removed from the ERO.
The rest of the steps for the loose ERO processing follow
procedure outlined in [RFC3209].
. If the node understands the Metric subobject but cannot find
a route to the next abstract node such that the requested
metric bound(s) can be satisfied, it SHOULD send a Path Error
with error code "Routing Problem" and a new error subcode "No
route available toward destination with the requested metric
bounds". The error subcode "No route available toward
destination with the requested metric bounds" for Path Error
code "Routing Problem" is to be assigned by IANA (Suggested
Value: 109).
3. Security Considerations
This document does not introduce any additional security issues
above those identified in [RFC5920], [RFC2205], [RFC3209], and
[RFC3473].
4. IANA Considerations
This document adds the following two new subobject of the
existing entry for ERO (20, EXPLICIT_ROUTE):
Value Description
----- ------------
TBA (suggest value: 66) Objective Function (OF) subobject
TBA (suggest value: 67) Metric subobject
These subobject may be present in the Explicit Route Object, but
not in the Route Record Object.
Ali, Swallow, Filsfils Expires September 2012 [Page 10]
ID draft-ali-ccamp-rc-objective-function-metric-bound-00.txt
OF Code values carried in OF subobject requires an IANA entry
with suggested values as defined in section 2.1.
5. Acknowledgments
Authors would like to thank Matt Hartley, Ori Gerstel, Gabriele
Maria Galimberti, Luyuan Fang and Walid Wakim for their review
comments.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[IEEE.754.1985] IEEE Standard 754, "Standard for Binary
Floating-Point Arithmetic", August 1985.
6.2. Informative References
[RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) -- Version 1 Message Processing
Rules", RFC 2209, September 1997.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
Authors' Addresses
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
George Swallow
Cisco Systems, Inc.
swallow@cisco.com
Ali, Swallow, Filsfils Expires September 2012 [Page 11]
ID draft-ali-ccamp-rc-objective-function-metric-bound-00.txt
Clarence Filsfils
Cisco Systems, Inc.
cfilsfil@cisco.com
Ali, Swallow, Filsfils Expires September 2012 [Page 12]