Network Working Group J.L. Le Roux
France Telecom
Internet Draft
D. Papadimitriou
Alcatel
Category: Standard Track
Expires: April 2006 October 2005
Handling Path Constraints in Generalized RSVP-TE signaling
draft-leroux-ccamp-rsvp-te-path-constr-01.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.
This Internet-Draft will expire on April 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 1]
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
Abstract
In various situations, it would be useful to include aggregated path
parameters such as, e.g., delay, hop-count or optical power, within
Generalized MPLS signaling. For that purpose, this draft extends
GMPLS RSVP-TE, for signaling end-to-end path constraint, and
aggregating path parameters along the path.
This draft only defines generic encoding rules and procedures.
Specific encoding and procedures for each path parameter will be
addressed in separate documents.
Table of Contents
1. Terminology.................................................3
2. Introduction................................................3
3. Overview of the mechanism...................................4
4. The Path_Constraints TLV....................................5
4.1. Description.................................................5
4.2. Format......................................................5
4.2.1. Path Parameter sub-TLV......................................6
4.3. Elements of procedure.......................................6
5. The AGGREGATION object......................................7
5.1. Format......................................................7
5.2. Elements of procedure.......................................7
6. Procedures to setup a TE-LSP with Path_Constraints..........8
6.1. Procedure for the Head-End LSR..............................8
6.2. Procedure for a transit/tail-end LSR........................8
7. Procedures for Bidirectional LSPs..........................10
8. Procedures for inter-domain LSPs...........................10
9. IANA Consideration.........................................10
9.1. New RSVP C-Num and C-Type..................................10
9.2. New LSP Attributes TLV.....................................10
9.3. New Path Parameters TLV Space:.............................10
9.4. New Error Codes............................................11
9.5. Security issues............................................11
10. Normative References.......................................11
11. Informative References.....................................12
12. Authors' Address:..........................................12
13. Intellectual Property Statement............................12
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.
Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 2]
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
1. Terminology
This document uses terminology from the MPLS architecture document
[RFC3031] and from the RSVP-TE protocol specification [RFC3209] which
inherits from the RSVP specification [RFC2205]. It also makes uses of
the Generalized MPLS RSVP-TE terminology introduced in [RFC3471] and
[RFC3473].
2. Introduction
GMPLS control plane (see [GMPLS-ARCH]) supports routing and signaling
of TE-LSPs for various switching technologies (PSC, L2SC, TDM, LSC,
FSC). Those generalized TE LSPs are routed along paths that respect a
set of TE constraints. Various TE constraints can be taken into
account during path computation, such as, for instance, bandwidth,
delay, hop-counts, and resource affinities.
There are actually two types of TE LSP constraints:
- Link constraints: bandwidth, affinities, etc.
- Path_Constraints: delay, hop count, power loss, etc.
Some path constraints such as delay or hop count apply to any
switching capability. Some other path constraints apply only to a
subset of switching capabilities, such as power loss for instance.
GMPLS Path parameters such as delay, hop count, power loss result
from the aggregation of link parameters. Such aggregation is
actually an addition of link parameters along the path. For instance
the delay of a path is the sum of hop delays.
Current Generalized RSVP-TE [RFC3473] signals, and performs local
admission control based on link constraints only. Path Constraints
are not signaled within RSVP-TE.
However in some situations, it would be useful to signal Paths
Constraints, and aggregate link parameters values along the path, in
order to perform an admission control based also on Path_Constraints.
This includes the following situations:
- The TE-LSP path has been computed taking into account
Path_Constraints, but with incomplete information on link
parameters, or estimated link parameters. In that case it
is useful to signal Path Constraints, and to aggregate link
parameters along the path, so as to let LSRs perform
admission control based on signaled constraints and aggregated
link parameter(s). Also it is useful to reflect actual
aggregated path parameters value back to the Head-End LSR.
- In an inter-domain domain context (inter-area, inter-AS) it
may be useful to signal Path_Constraints, and to aggregate
link parameters, so that a border router can take them into
account when doing ERO expansion (case of per-domain path
Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 3]
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
computation in [PD-PATH-COMP]). Also it may be useful to
indicate to the head-end LSR the actual values of path
parameters, as they cannot be deduced from the RRO.
This draft defines Generalized RSVP-TE protocol extensions to allow
for signaling of Path_Constraints, and for aggregation of link
parameters along the path.
The document is built as follows:
- Section 3 gives an overview of the solution.
- Section 4 defines a new Path Constraints TLV, to be carried
within the LSP_REQUIRED_ATTRIBUTE object, and used to encode Path
Constraints.
- Section 5 defines a new object called the AGGREGATION object,
used to build path parameters based on an aggregation of
link parameters along the signaled path.
- Finally, section 6 defines elements of procedures for head-end,
transit, and tail-end LSRs.
This document only defines generic encoding and procedures. Specific
Encoding and procedures depend on each path parameter and will be
addressed in separate documents.
Note that procedures specific to the inter-domain case (inter-area or
inter-AS) will be addressed in a future revision.
3. Overview of the mechanism
As mentioned in the previous section, it would be useful in various
situations (e.g. loose paths), to signal Path_Constraints such as
maximum delay or maximum hop count within RSVP-TE, and to aggregate
associated link parameters along the path, in order to determine
actual path parameters such as path delay or path hop count, and
perform admission control on these parameters.
A new Path Constraints TLV is defined for being carried within the
LSP_REQUIRED_ATTRIBUTE object [LSP-ATTR]. It is used to carry
upper bounds for a set of path parameters. These values are fixed by
the head-end LSR and are not modified along the path.
A new RSVP AGGREGATION object is defined so as to aggregate link
parameter values along the path and determine end-to-end path
parameters. It is updated at each hop, basically each hop combines
received value with its own contribution to the path parameter.
The procedures to signal an LSP with Path_Constraints are as follows:
- The head-end sends a Path message that includes:
Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 4]
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
- A Path Constraints TLV, included in a LSP_REQUIRED_ATTRIBUTE
object, that carries a set of path constraints.
- An AGGREGATION object that contains a set of path
parameters, initially set to the least significant value.
- On each LSR along the path, each value included in the
AGGREGATION object is updated based on local hop contribution to
each path parameter. Admission control is then performed for each
parameter included in the Path_Constraints TLV. The aggregate
value in the AGGREGATION object is compared with the path
constraint value included as part of the Path Constraints TLV.
- If all constraints are respected then if the LSR is at transit
the Path message is propagated downstream and if the LSR is at
tail-end, the AGGREGATION object is reflected in a Resv message
and passed unchanged back to the head-end LSR. .
- In case one (or more) constraints are violated, the LSR
sends back a PathErr message with the Path_State_Removed flag
Set [RFC3473], and with a new Error code and value that
indicates the violated constraint. The PathErr message also
includes the AGGREGATION object that is passed unchanged back
to the head-end LSR.
4. The Path_Constraints TLV
4.1. Description
The Path_Constraints TLV is defined as a new Attribute TLV of the LSP
REQUIRED ATTRIBUTE object. It exactly follows the processing rules
defined in [LSP-ATTR].
It contains a set of Path Parameter sub-TLVs, each encoding the
constraint value for a given path parameter.
4.2. Format
The Path Constraints TLV is encoded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Path Parameters sub-TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 5]
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
Type: Path_Constraints
IANA has been asked to manage the space of TLV types in the
REQUIRED_LSP_ATTRIBUTES Object [LSP-ATTRIB]. This document suggest
Type = 2 for the Path Constraints TLV.
Value: A set of one or more Path Parameter sub-TLVs
4.2.1. Path Parameter sub-TLV
A path parameter sub-TLV encodes the value of a path
parameter. It can be carried within a Path Constraints TLV of an
LSP_REQUIRED_ATTRIBUTE object, or an AGGREGATION object. It 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Path Parameter Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X: Break bit, used to indicate that at least one LSR on the path
did not recognize and proceed the parameter.
Type: 15 bits identifier of the path parameter.
Length:
The length of the value field in bytes. Thus if no value field
is present the length field contains the value zero.
Each value field must be zero padded at the end to take it up
to a four byte boundary - the padding is not included in the
length so that a one byte value would be encoded in an eight
byte TLV with length field set to one.
Path Parameter Value:
Scalar value of the path parameter. The unit will depend on
on the type of parameter and will be defined in the document
that introduces the parameter.
4.3. Elements of procedure
Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 6]
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
An LSR that does not recognize the Path Constraints TLV or recoginze
it but does not support it MUST reject the Path message using an
Error code "Unknown Attributes TLV" and an error value identifying
the unknown TLV type code.
An LSR that does not recognize a parameter type in the Path
Constraint TLV MUST set the break bit for this parameter.
5. The AGGREGATION object
The AGGREGATION object is used to build path parameters, by
cumulating hop parameters along the signaled path.
It is carried within a Path message and updated at each hop. This
object is also be carried in Resv and PathErr message, where it is
passed unchanged.
5.1. Format
The AGGREGATION object contains a set of Path Parameter TLVs
whose encoding is defined in 4.2.1. Each TLV corresponds to a given
accumulated parameter along the path.
Note that a given parameter must have the same TLV type, when carried
in the LSP_REQUIRED ATTRIBUTE object or in the AGGREGATION object.
Class = 0bbbbbbb, C-Type = Path Parameter TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
// Path Parameter TLVs //
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. Elements of procedure
The AGGREGATION object has a C-Num of form 0bbbbbbb. That is, an LSR
that does not recognize this object should reject the LSP and send
back a PathErr with the appropriate error code.
An LSR that does not recognize a parameter type in AGGREGATION object
MUST set the break bit for this parameter.
Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 7]
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
6. Procedures to setup a TE-LSP with Path Constraints
6.1. Procedure for the Head-End LSR
To signal a LSP subject to a set of path constraints, the head-end
LSR sends a Path message that contains a Path Constraints TLV
included within a LSP_REQUIRED_ATTRIBUTE object. Path_constraints are
encoded within Path Parameter sub-TLVs.
Note that the type of constraints and constraint values may be
subject to change during the life of the LSP but are under full
control of the head-end LSR.
The Path message sent by the head-end LSR also contains an
AGGREGATION object. Values in path parameters TLVs are initialized
following rules specific to each parameter. These specific rules are
out of the scope of this document, and will be addressed in documents
introducing the parameters.
Note that all path parameters present in the Path_Constraints TLV,
MUST also appear in the AGGREGATION Object. In return some path
parameters not subject to admission control may be present in the
AGGREGATION object, and not in the Path_Constraints TLV.
Note that the break bit of all parameters in the AGGREGATION object
and the Path Constraints TLV MUST be initially cleared.
On receipt of a Resv message with a AGGREGATION object, the head-end
LSR will be aware of the current LSP path parameters. The processing
of these values by the Head-End LSR will be addressed in documents
defining the path parameters.
6.2. Procedure for a transit/tail-end LSR
On receipt of a Path message with an AGGREGATION object and no Path
Constraint TLV, an LSR MUST update each recognized and supported path
parameter of the AGGREGATION object. For each path parameter it has
to accumulate the received value with its own "contribution" to the
parameter. If the LSR does not recognize or recognize but does not
support a given path parameter it should set the break bit of this
parameter to 1.
If the LSR is at transit it MUST forward the Path message downstream
with the updated AGGREGATION object. If the LSR is at tail-end it
MUST reflect the updated AGGREGATION object in a Resv message sent
back to the head-end LSR.
On receipt of a Path message with an AGGREGATION object and a Path
Constraint TLV in the LSP_REQUIRED_ATTRIBUTE object, an LSR MUST
firstly update each path parameter of the AGGREGATION object. If a
parameter is not recognized it should set the break bit of this
parameter to 1. Then it MUST perform local admission control for each
recognized and supported path parameter included in the Path
Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 8]
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
Constraints TLV, by verifying that aggregated path parameters does
not exceed path constraints.
- If all constraints are respected and all break bit are cleared
then if the LSR is at transit the Path message is forwarded
downstream with the updated AGGREGATION object and if the LSR
is at tail-end the updated AGGREGATION object is included in a
Resv message sent back to the head-end LSR.
- If at least one constraint is violated, then the LSP MUST be
rejected, whatever the break bit value and a PathErr is sent
back to the Head-End LSR with the Path_State_Removed flag set
and a new Error code ("path constraint violation"), and error
value corresponding to the TLV type of the violated
constraint. This PathErr message MUST also reflect the
AGGREGATION object unchanged.
- If at least one locally supported parameter has the break bit
set and the constraint is respected, then the LSP may be
rejected or not depending on local policy decision. If it is
rejected a PAthErr message with the error code "Unsupported
Path Parameter" and error value corresponding to the
unsupported TLV type MUST be generated.
This PathErr message MUST also reflect the AGGREGATION object
unchanged.
- If there is at least one locally unsupported parameter then
the LSP may be rejected or not depending on local policy
decision. If it is rejected a PAthErr message with the error
code "Unsupported Path Parameter" and error value
corresponding to the unsupported TLV type MUST be generated.
This PathErr message MUST also reflect the AGGREGATION object
unchanged.
Note that path parameters included in the AGGREGATION object, but not
in the Path Constraints TLV are not subject to a local admission
control.
When its local contribution changes, a transit LSR SHOULD perform
admission control and send a Path message downstream with an updated
AGGREGATION object.
An AGGREGATION object included in a Resv message MUST be forwarded
transparently by a transit LSR.
The Path_Constraints TLV included in a Path/Resv message MUST be
forwarded transparently by a transit LSR.
The Break bit of a parameter TLV MUST never be cleared by any LSR.
Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 9]
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
7. Procedures for Bidirectional LSPs
TBD
8. Procedures for inter-domain LSPs
TBD
9. IANA Consideration
9.1. New RSVP C-Num and C-Type
One new RSVP C-Num is defined in this document and should be
assigned by IANA.
o AGGREGATION object
The C-Num should be of the form 0bbbbbbb so that LSRs that do not
recognize the object reject the LSP.
One C-Type is defined for this object and should be assigned by IANA.
o Path Parameter TLVs
Recommended C-Type value = 1.
9.2. New LSP Attributes TLV
This document defines one LSP Attributes TLV type as
follows:
- TLV Type Suggested value = 2
- TLV Name = Path_Constraints
- allowed on LSP_REQUIRED_ATTRIBUTES object.
9.3. New Path Parameters TLV Space:
The AGGREGATION object and the Path Constraints TLV defined above are
constructed from TLVs. Each TLV correspond to a particular path
parameter. Each TLV includes a 15-bit type identifier (the T-field).
The same T-field values are applicable to the AGGREGATION object and
the Path Constraints TLV.
IANA is requested to manage Path Parameter TLV type identifiers as
follows:
- TLV Type (T-field value)
- TLV Name: Name of the Path Parameter
- RFC:
Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 10]
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
9.4. New Error Codes
This document defines the following new RSVP error codes and error
values. Numeric values should be assigned by IANA.
Error Code Error Value
"Unknown Path parameter TLV" Identifies the unknown TLV type code.
"Path Constraint Violation" Identifies the TLV type of the
violated constraint.
9.5. Security issues
This document adds one new object to the RSVP Path/Resv message, and
a new TLV to the LSP_REQUIRED_ATTRIBUTE object.
It does not introduce any new direct security issues and the reader
is referred to the security considerations expressed in [RFC2205],
[RFC3209] and [RFC3473].
10. Normative References
[RFC2119] 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.
[RFC3668] Bradner, S., Ed., 'Intellectual Property Rights in IETF
Technology', BCP 79, RFC 3668, February 2004.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
'Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
Specification', RFC 2205, September 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.
[RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling -
RSVP-TE Extensions", RFC 3473, January 2003.
[LSP-ATTR] A. Farrel, et. al. , "Encoding of Attributes for MPLS LSP
Establishment Using RSVP-TE" draft-ietf-mpls-rsvpte-
attributes, work in progress.
Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 11]
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
11. Informative References
[GMPLS-ARCH] E.Mannie (Editor) et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Architecture", Internet Draft,
Work in Progress, draft-ietf-ccamp-gmpls-architecture-
07.txt, May 2003.
[PD-PATH-COMP] Vasseur, J.P., Ayyangar, A., Zhang, R., " 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.
12. Authors' Address:
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
jeanlouis.leroux@francetelecom.com
Dimitri Papadimitriou
Alcatel
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Phone : +32 3 240 8491
EMail: dimitri.papadimitriou@alcatel.be
13. 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
Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 12]
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
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 THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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.
Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 13]