Internet DRAFT - draft-dolganow-pce-cost-object
draft-dolganow-pce-cost-object
Network Working Group Andrew Dolganow(Editor)
Alcatel.
JP Vasseur
Cisco System Inc.
Proposed Status: Standard
Expires: April 2006 October 2005
A new object to specify a Traffic Engineering (TE) Label Switch Path
(LSP) cost
draft-dolganow-pce-cost-object-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document proposes a new object (named the COST object) used to
specify the cost of a Traffic Engineering (TE) Label Switched Path
(LSP). The COST object can be carried within an RSVP message so as to
record a TE LSP cost during LSP establishment or within a Path
Computation Element (PCE) path computation protocol message so as to
Dolganow, et al. [Page 1]
Internet Draft draft-dolganow-pce-cost-object October 2005
provide the cost of a computed path to a Path Computation Client
(PCC).
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents
1. Note............................................................2
2. Terminology.....................................................2
3. Introduction....................................................3
4. Collecting path cost in RSVP signaling..........................3
5. Recording path cost in PCEP path computation reply messages.....4
6. Signalling details..............................................4
6.1. COST object body format.......................................4
6.2. Changes to RSVP signalling....................................4
6.2.1. COST Object format in RSVP..................................4
6.2.2. Changes to Attributes Flags TLV and RRO Attributes subobject 5
6.2.3. RSVP object and message applicability.......................5
6.3. Changes to PCEP signalling....................................5
6.3.1. COST object format in PCEP..................................6
6.3.2. PCEP message applicability..................................6
7. Elements of procedure...........................................6
7.1. Changes to RSVP signalling....................................7
7.2. Changes to PCEP signalling....................................8
8. Future work.....................................................8
9. IANA Considerations.............................................8
9.1. Changes required to RSVP......................................8
9.2. Changes required to PCEP......................................8
10. Intellectual Property Statement................................9
11. Acknowledgment.................................................9
12. References.....................................................9
12.1. Normative references.........................................9
13. Authors’ Addresses............................................10
1. Note
This document contains proposal to extend both PCEP and RSVP
protocols. The authors have the intention of splitting this document
into two separate drafts (one for PCEP and one for RSVP) once the
content stabilizes. A single draft is used for now to better
coordinate comments coming on this proposal from various groups (PCE
and CCAMP) and to focus discussion around a single point of
reference.
2. Terminology
Terminology used in this document
Inter-domain TE LSP: A TE LSP whose path transits across at least
Dolganow, et al. [Page 2]
Internet Draft draft-dolganow-pce-cost-object October 2005
two different domains where a domain can either be an IGP area, an
Autonomous System or a sub-AS (BGP confederations).
PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.
PCEP: Path Computation Element communication Protocol
PCEP Peer: a PCC or the PCE involved in a PCEP session.
PLR: Point of Local Repair (as defined in [RSVP-FASTREROUTE])
Within this document, when PCE-PCE communications are being
described, the requesting PCE fills the role of a PCC. This provides
a saving in documentation without loss of function.
3. Introduction
There are various circumstances whereby the head-end of a TE LSP does
not have the ability to get the cost of a computed TE LSP. Inter-
domain TE LSP computation using the per-domain path computation
approach described in [INTER-DOMAIN-PD-PATH-COMP] is an example where
each segment is computed by boundary nodes; consequently, although
the head-end LSR can determine the computed path by means of an RSVP
RRO object it cannot determine the path cost. Another example is when
a PCE-based path computation is used to compute TE LSP (see [PCE-
ARCH]). In such a case, the head-end LSR (acting as a PCC) may
request the PCE to provide the cost of a computed path.
The cases described above require the specification of a new object
to be carried within an RSVP message upon signaling or within a path
computation reply message as described in the Path Computation
Element Communication Protocol (PCEP) [PCE-PCEP].
Providing a total path cost will allow the head-end LSR of TE LSP
offer new services. Services using the collected path cost are out of
scope for this document.
4. Collecting path cost in RSVP signaling
To collect the cost of a TE LSP, the head-end LSR includes in the
RSVP Path message an LSP-ATTRIBUTES object with Attribute Flags TLV
with a “Path cost requested” flag set (see section 5 for definition).
The TLV is passed transparently towards a tail-end LSR. When the
tail-end LSR receives the RSVP Path message, the LSR places in the
corresponding RSVP Resv message the RRO Attributes Subobject with the
Dolganow, et al. [Page 3]
Internet Draft draft-dolganow-pce-cost-object October 2005
“Path cost” flag set inside the RECORD ROUTE Object as described in
the [RSVPTE-ATTR]. The cost value inside the COST object is set to 0.
Every LSR the message traverses, increments the cost value inside the
COST Object with the cost of its downstream link and adds RRO
Attributes Subobject with the “Path cost” flag set to the RECORD
ROUTE Object. The absence of the RRO Attributes Subobject with the
“Request path cost” flag set for any hop indicates to the head end
LSR that the accumulated path cost does not represent the total path
cost.
5. Recording path cost in PCEP path computation reply messages
In some cases a PCC may find it desirable to know the cost of the
computed path returned by a PCE. Mechanism to request such a cost is
already defined in the PCEP. To return the cost to the PCC upon
successful path computation, the PCE includes in the PCRep message
defined in [PCE-PCEP] the cost of the computed path using the COST
object as defined later on in this document. PCC may then use the
returned cost as required.
When a PCE cannot return the computed path cost (e.g. because of
policy) or when a PCRep message does not contain the COST object with
the computed path cost, normal PCEP error procedures apply.
6. Signalling details
6.1. COST object body format
The format of the COST object body is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 – COST object body format
Cost value: 4 octets –A 32-bit unsigned integer specifying the
computed path cost.
6.2. Changes to RSVP signalling
6.2.1. COST Object format in RSVP
The COST object is an optional object carried in RSVP Resv message to
collect the cost of a TE LSP. The object is added by a tail-end LSR
that supports path cost accumulation when such an accumulation was
requested by the head-end LSR and is updated by LSRs that support the
Dolganow, et al. [Page 4]
Internet Draft draft-dolganow-pce-cost-object October 2005
object and path cost accumulation for a given TE LSP. LSRs that do
not understand the object or have elected not to participate in path
cost accumulation for this LSP pass this object unchanged in the Resv
message they generate.
The COST Object class is TBD of the form 11bbbbbb. This C-num value
ensures that LSRs that do not recognize the object pass it on
transparently.
One C-Type is defined, C-Type = 1 for Path Cost (TBD)
The format of the COST object in RSVP is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (bytes) | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Cost object body //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 – COST object format for RSVP
Cost object body – Body of the cost object with format as defined in
section 6.1 above
6.2.2. Changes to Attributes Flags TLV and RRO Attributes subobject
The new flag is defined to allow head-end LSR requesting path cost
accumulation and to allow LSRs reporting if the cost accumulation
took place.
Flag value:
Bit 5 (TBD) – “Path cost” flag (to be assigned by IANA)
6.2.3. RSVP object and message applicability
The Attribute Flags TLV with the “Path cost” flag set is included by
head-end LSR in the LSP_ATTRIBUTES Object in the Path message to
request path cost accumulation.
The RRO Attributes Subobject with the “Path cost” flag set is
included by every LSR in the RECORD ROUTE_ Object in the Resv message
to indicate that the LSR performed the path accumulation.
The COST object is included by tail-end LSR in the Resv message to
accumulate TE-LSP path cost.
6.3. Changes to PCEP signalling
Dolganow, et al. [Page 5]
Internet Draft draft-dolganow-pce-cost-object October 2005
6.3.1. COST object format in PCEP
A new PCEP object named the COST object is defined. When carried as
part of a PCRep message, the COST object must be preceded by the
Common object header format as defined in [PCE-PCEP] with the
following coding points:
COST Object-Class is to be assigned by IANA (recommended value=14)
COST Object-Type is to be assigned by IANA (recommended value=1)
The format of the COST object in PCEP is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class |Object-Type|P|R| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Cost object body //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 – COST object format for PCEP
Cost object body – Body of the cost object with format as defined in
section 6.1 above
6.3.2. PCEP message applicability
The COST object is an optional object that may be carried as part of
a PCRep message. The format of the <path> defined in [PCE-PCEP]
returned as part of PCRep message is modified as follows to account
for the COST object:
<path>::=<RP>
[<NO-PATH>]
[<ero-list>]
[<LSPA>]
[<BANDWIDTH>]
[<DELAY>]
[<XRO>]
[<IRO>]
[<COST>]
When a COST object is part of any other PCEP message, the common PCEP
error rules MUST apply.
7. Elements of procedure
Dolganow, et al. [Page 6]
Internet Draft draft-dolganow-pce-cost-object October 2005
7.1. Changes to RSVP signalling
General rules for processing of LSP_ATTRIBUTES Object and RRO
Attributes Subobject as defined in [RSVPTE-ATTR] apply with the
following details:
1. Head-end LSR may include Attributes TLV with “Path cost” flag
set within LSP-ATTRIBUTES object in the RSVP Path message to
request path cost accumulation. The LSR must extract the path
cost from the COST object in a corresponding RSVP Resv message
and increment it by its downstream link to obtain the current
path cost for the TE LSP. Head-end LSR should examine the RRO
object to determine if the cost accumulated is of the entire
path or not (based on RRO Attributes Subobjects added by each
node along the LSP path).
Actions performed by Head-end LSR when the total path cost is
collected or is not known (as determined based on the received
RSVP Resv message) are out of the scope of this document.
2. Any transit LSR MUST not modify the “Path cost” flag set within
the Attributes TLV within LSP-ATTRIBUTES in the received RSVP
Path message and:
a. SHOULD include in the corresponding RSVP Resv message RRO
Attributes Subobject with “Path cost” flag set and
increment Cost value in the COST object with the cost of
its downstream link, if it supports path cost accumulation
as described in this document.
b. MUST NOT update in the corresponding RSVP Resv message RRO
Attributes Subobject with “Path cost” flag set and MUST
pass COST object unchanged if it does not supports path
cost accumulation as described in this document or if it
elects not to provide path accumulation for this LSP setup.
3. Tail-end LSR upon receiving an RSVP Path message including
Attributes TLV with “Path cost” flag set within the LSP
ATTRIBUTES:
a. SHOULD include in the corresponding RSVP Resv message RRO
Attributes Subobject with “Path cost” flag set and COST
object with cost value set to 0, if it supports path cost
accumulation as described in this document.
b. MUST NOT include in the RSVP Resv message RRO Attributes
Subobject with “Path cost” flag set and MUST not include
COST object if it does not supports path cost accumulation
as described in this document or if it elects not to
provide path accumulation for this LSP setup.
When RSVP Fast Reroute is employed along the path, general rules for
failure processing apply as specified in [RSVP-FASTREROUTE]. The
updated Resv Message sent by PLR (Point of Local Repair) will include
the LSP-ATTRIBUTES, COST, and RRO objects of the path being activated
and the newly collected cost needs to be updated.
Dolganow, et al. [Page 7]
Internet Draft draft-dolganow-pce-cost-object October 2005
7.2. Changes to PCEP signalling
The COST object is carried within PCRep messages defined in [PCE-
PCEP]. As such elements of the procedures as applicable to optional
objects that are part of those messages apply as defined in [PCE-
PCEP] with the following details:
1. PCE SHOULD return the total cost of a computed path when
requested to do so in a PCReq message (see [PCE-PCEP] for
details on how to request the path cost to be returned). If the
PCE decides not to return the cost as requested by the PCC, the
Cost value inside the COST object SHOULD be set to 0.
2. The P bit value in the Common Object Header is not used and
SHOULD be set to 0 by the PCE.
8. Future work
Further revisions of this document will include the following
functional extensions:
1. The ability for the Head-end LSR or PCC to request a per-hop
cost recording function in addition to a cumulative TE LSP
cost.
2. Specification of the metric to be used (IGP or TE metric) to
record the TE LSP cost as part of the request.
3. Move of the request for return of a cost in PCRep from [PCE-
PCEP] into this document.
4. Split of the document into two as indicated in Section 1 above.
9. IANA Considerations
9.1. Changes required to RSVP
A new flag: “Path cost” for Attribute Flag TLV and RRO Attributes
Subobject is defined in this document. The value of the flag should
be assigned by IANA. The recommended value for the flag is Bit 5
(TBD).
A new COST object is defined to accumulate TE-LSP path cost value.
For that object:
1. The C-Num (To be assigned by IANA) should be of the form
11bbbbbb so that LSRs that do not recognize the object will
ignore the object but forward it, unexamined and unmodified in
all messages.
2. One C-Type is defined: C-Type = 1 (TBD) for Path Cost.
9.2. Changes required to PCEP
A new PCEP object named the COST object is defined in this document
that has a recommended Object-Class of 14 (TBD) and a recommended
Object-Type of 1 (TBD). The new Object-Class and Object-Type should
be assigned by IANA.
Dolganow, et al. [Page 8]
Internet Draft draft-dolganow-pce-cost-object October 2005
10. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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.
11. Acknowledgment
We would like to acknowledge input and helpful comments from Mustapha
Aissaoui, Adrian Farrel, and Jean-Louis Le Roux.
12. References
12.1. Normative references
[RFC] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
Dolganow, et al. [Page 9]
Internet Draft draft-dolganow-pce-cost-object October 2005
[RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[PCE-PCEP] JP. Vasseur, et al, “Path Computation Element (PCE)
communication Protocol (PCEP) – Version 1”, draft-vasseur-pce-pcep-
02.txt, September 2005.
[INTER-DOMAIN-PATH-COMP] JP. Vasseur and A. Ayyangar, “A Per-domain
path computation method for computing Inter-domain Traffic
Engineering (TE) Label Switched Path (LSP)”, draft-ietf-ccamp-inter-
domain-pd-path-comp (work in progress).
[PCE-ARCH] A. Farrel, J. Ash, JP. Vasseur, “Path Computation Element
(PCE) Architecture”, draft-ietf-pce-architecture (work in progress).
[RSVPTE-ATTR] draft-ietf-mpls-rsvpte-attributes, “Encoding of
Attributes for Multiprotocol Label Switching (MPLS) Label Switched
Paths (LSP) Establishment using RSVP_TE” (work in progress).
[RSVP-FASTREROUTE] Pan, P. et al, “Fast Reroute Extensions to RSVP-TE
for LSP Tunnels”, RFC 4090, May 2005.
13. Authors’ Addresses
Andrew Dolganow
Alcatel
600 March Rd., K2K 2E6 Ottawa, ON, Canada
Phone: +1 (613)784 6285
Email: andrew.dolganow@alcatel.com
Jean-Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
Email: jpv@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights."
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
Dolganow, et al. [Page 10]
Internet Draft draft-dolganow-pce-cost-object October 2005
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Dolganow, et al. [Page 11]
