CCAMP 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-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.
This Internet-Draft will expire on April 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In various situations, it would be useful to include path parameters
such as delay, jitter, number of hops, cost, optical power, within
Generalized MPLS signaling. For that purpose, this draft extends
GMPLS RSVP-TE, for signaling path constraint, and accumulating path
parameters. It defines protocol elements and procedures, that allow
signaling path_constraints and accumulating path parameters along the
signaled path.
TBD Standard Track - Expires March 2006 [Page 1]
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
This draft only defines generic encoding rules and procedures.
Specific encoding and procedures for each path parameter such as
delay, hop count, jitter will be addressed in separate documents.
Table of Contents
1. Terminology 2
2. Introduction 2
3. Overview of the Mechanism 4
4. 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 COMPOSITION 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 LSR 8
6.3. Procedure for tail-end LSRs 9
7. Bi-directional LSPs 9
8. IANA Consideration 9
8.1. New RSVP C-Num and C-Type 9
8.2. New LSP Attributes TLV 10
8.3. New Path Parameters TLV Space 10
8.4. New Error Codes 10
8.5. Security issues 10
9. Intellectual Property Considerations 10
10. Normative References 11
11. Informative References 11
12. Authors' Address 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.
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
Leroux et al. Standard Track - Expires March 2006 [Page 2]
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
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 two types of TE constraints:
- Link constraints: bandwidth, affinities, etc.
- Spatial Path_Constraints: delay, jitter, hop count, etc.
- Spectral Path Constraints: polarization, signal power, etc.
Some GMPLS Path_Constraints such as jitter apply only to statistical
multiplexing layers (PSC, L2SC). Some constraints such as
polarization or signal power, applies only to photonic layers. Some
other constraints such as hop count apply to any switching layer.
GMPLS Path parameters such as delay, hop count, signal power result
from the combination of link parameters. Their composition can be a
simple accumulation / reduction function but this may be a more
complex function. For instance the delay of a path is simply the
accumulation 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 there are some cases where it would be useful to signal paths
constraints, and combine link parameters values along the path, in
order to perform an admission control a tail-end LSR, based on
Path_Constraints. This includes the following cases:
- 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 constraint, and combine link
parameters along the path, to let the tail-end perform
admission control based on signaled constraints with
respect to the composition of the corresponding link
parameter(s). Also it is also useful to reflect actual path
parameters value back to the Head-End LSR.
- In case of inter-domain LSP it may be useful to signal
Path_Constraints, and accumulate link parameters, so that a
border router can take them into account when doing ERO
expansion (case of per-domain path computation in [INTER-
DOMAIN-COMP]).
This draft defines Generalized RSVP-TE protocol extensions to allow
for signaling of Path_Constraints, and accumulation of link
parameters along the path.
Leroux et al. Standard Track - Expires March 2006 [Page 3]
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
The document is built as follows:
- Section 3 gives an overview of the solution.
- Section 4 defines a new Path Constraint TLV, to be carried within
the LSP_REQUIRED_ATTRIBUTE object, and used to encode Path
Constraints.
- Section 5 defines a new object called the COMPOSITION object, used
to build path parameters based on a composition 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, procedures and accumulation rules is path parameter such as
delay, hop count, jitter and LSP class specific and will be addressed
in separate documents.
3. Overview of the Mechanism
As mentioned in the previous section, it would be useful in various
situations to signal Path_Constraints such as maximum delay or
maximum hop count (in particular during for loose paths), within
RSVP-TE, and to combine link parameters along the path, in order to
determine path parameters such as path delay or path hop count.
A new Path Constraints TLV is defined for being carried within the
LSP_REQUIRED_ATTRIBUTE object [LSP-ATTR]. It is used to carry
particular value such as upper or lower bounds for a set of path
parameters or a value range. Values are fixed by the head-end LSR and
are not modified along the path.
A new COMPOSITION object is defined to compose link parameter values
and determine end-to-end significant parameters along the path of the
LSP. It is updated at each hop, basically each hop combines received
value with its own contribution to the path parameter.
The procedure to signal an LSP with Path_Constraints is as follows:
- The head-end sends a Path message that includes:
- A Path Constraints TLV, included in a LSP_REQUIRED_ATTRIBUTE
object, that encodes for each path constraint a set of
parameters.
- An COMPOSITION object that contains a set of path
parameters, initially set to the least significant value.
- At each transit LSR, each value included in the COMPOSITION
object value is updated based on local hop contribution to
each path parameter. It is assumed that the composition function
is uniquely defined for each of these parameters.
- The tail-end LSR performs admission control for each
parameter included in the Path_Constraints TLV. For each
Leroux et al. Standard Track - Expires March 2006 [Page 4]
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
parameter, the composed value in the COMPOSITION object is
compared with the constraint value included as part of the Path
Constraints TLV.
Admission control formulas are specific to each parameter
and are not addressed in this document. If all constraints
are acceptable by the tail-end LSR, the later sends back a
Resv message, reflecting the COMPOSITION object that is passed
unchanged back to the head-end LSR.
- In case one (or more) constraints are violated, the tail-end LSR
sends 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
COMPOSITION object that is passed unchanged back to the head-end
LSR.
4. 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. Path Parameter sub-TLVs
are to be specified on a per QoS service basis.
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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Leroux et al. Standard Track - Expires March 2006 [Page 5]
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
4.2.1. Path Parameter sub-TLV
Each path parameter sub-TLV encodes constraint value of a path
parameter. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Path Parameter Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
The 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
An LSR that does not recognize a parameter type in the Path
Constraint TLV MUST reject the Path message using a Path Error with
Error Code "Unknown Path Parameter" and Error Value set to the
parameter type.
To avoid high rejection rate, a break bit (X) is introduced.
Moreover, as values can be correlated to deliver a given service, it
is expected that the processing of this bit will be defined such that
it applies to the set of the corresponding Path Parameter sub-TLVs.
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 |X| Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Leroux et al. Standard Track - Expires March 2006 [Page 6]
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
| |
// Path Parameter Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. The COMPOSITION object
The COMPOSITION object is used to build path parameters, by combining
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, with no update at any hop.
5.1. Format
The COMPOSITION object contains a set of Composed Path Parameter TLVs
whose encoding is defined in 2.2.1, each TLV corresponding to a given
accumulated parameter along the path.
Note that a given parameter must have the same type, when carried in
the LSP_REQUIRED ATTRIBUTE object or in the COMPOSITION object.
Class = 10bbbbbb, C-Type = Composed Path Parameter TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
// Composed Path Parameter TLVs //
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
To avoid a too massive rejection break bit (X) is introduced.
Moreover, as values can be correlated to deliver a given service, it
is expected that the processing of this bit will be defined such that
it applies to the set of the corresponding sub-TLVs.
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 |X| Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Composed Parameter Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. Elements of procedure
The ACCUMLATOR object has a C-Num of form 10bbbbbb. That is, an LSR
that does not recognize this object should discard it silently.
Leroux et al. Standard Track - Expires March 2006 [Page 7]
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
An LSR that recognize this object but does not recognize a path
parameter should set the break bit X. It is upon tail-end LSR
decision (and subsequently the head-end LSR) to decide whether a non-
complete composition is satisfactory or not for the whole Path.
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
COMPOSITION 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 COMPOSITION Object. In return some path
parameters not subject to admission control may be present in the
COMPOSITION object, and not in the Path_Constraints TLV.
On receipt of a Resv message with a COMPOSITION 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 LSR
A Transit LSR MUST update each path parameter of a COMPOSITION object
received in a Path message, and forward the updated object in the
Path message sent downstream. Basically, for each path parameter it
should combine the received value with its own "contribution" to the
parameter. Combination rule depend on the parameter type, and must be
addressed in the document defining the path parameter.
When its local contribution changes, a transit LSR SHOULD send a Path
message downstream with an appropriately updated COMPOSITION object.
A COMPOSITION 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.
Leroux et al. Standard Track - Expires March 2006 [Page 8]
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
6.3. Procedure for tail-end LSRs
On receipt of a Path message containing a COMPOSITION object and no
Path_Constraints TLV, a tail-end LSR MUST reflect the COMPOSITION
object unchanged in a Resv message upstream to the head-end LSR.
On receipt of a Path message containing both a COMPOSITION object and
a Path_Constraints TLV in the LSP_REQUIRED_ATTRIBUTE object, the
tail-end LSR MUST perform an admission control for each path
parameter constraint in the Path_Constraints TLV. Each path parameter
constraint must be compared, with the accumulated parameter value.
Comparison rules will be addressed in documents defining the path
parameters.
If no constraint is violated, the COMPOSITION object MUST be
reflected unchanged in a Resv message sent upstream.
If at least one constraint is violated, the LSP must be rejected, and
the tail-end LSR must send a PathErr message with the
Path_State_Removed flag set, and with a new Error code (path
constraint violation, and error value corresponding to the violated
constraint.
This PathErr message MUST also reflect the COMPOSITION object
unchanged.
7. Bi-directional LSPs
TBD
8. IANA Consideration
8.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 COMPOSITION object
The C-Num should be of the form 10bbbbbb so that LSRs that do not
recognize the object will ignore the object and discard it silently.
One C-Type is defined for this object and should be assigned by IANA.
o Path Parameter TLVs
Recommended C-Type value 1.
Leroux et al. Standard Track - Expires March 2006 [Page 9]
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
8.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.
8.3. New Path Parameters TLV Space:
The COMPOSITION object and the Path Constraints TLV defined above are
constructed from TLVs. Each TLV correspond to a particular path
parameter. Each TLV includes a 16-bit type identifier (the T-field).
The same T-field values are applicable to the COMPOSITION object and
the Path Constraints TLV.
IANA is requested to manage TLV type identifiers as follows:
- TLV Type (T-field value)
- TLV Name
8.4. New Error Codes
This document defines the following new 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 Violaton" Identifies the TLV type of the violated
constraint.
8.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].
9. Intellectual Property Considerations
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.
Leroux et al. Standard Track - Expires March 2006 [Page 10]
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
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.
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", Work in Progress,
draft-ietf-mpls-rsvpte-attributes-05.txt, May 2005.
11. Informative References
[GMPLS-ARCH] E.Mannie (Editor) et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Architecture", RFC 3945, October
2005.
[INTER-DOMAIN-COMP] Vasseur JP., Ayyangar A., Zhang R., "Inter-
domain MPLS Traffic Engineering LSP path
Leroux et al. Standard Track - Expires March 2006 [Page 11]
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
computation methods", (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. 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 THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Leroux et al. Standard Track - Expires March 2006 [Page 12]