CCAMP
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-00.txt
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).
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 as, e.g., delay, jitter, number of hops, cost, 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 accumulating path
parameters. It defines protocol elements and procedures, that allow
signaling path_constraints and accumulating
aggregating path parameters along the
signaled path.
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 Terminology.................................................3
2. Introduction 2 Introduction................................................3
3. Overview of the Mechanism 4 mechanism...................................4
4. The Path_Constraints TLV 5 TLV....................................5
4.1. Description 5 Description.................................................5
4.2. Format 5 Format......................................................5
4.2.1. Path Parameter sub-TLV 6 sub-TLV......................................6
4.3. Elements of procedure 6 procedure.......................................6
5. The COMPOSITION object 7 AGGREGATION object......................................7
5.1. Format 7 Format......................................................7
5.2. Elements of procedure 7 procedure.......................................7
6. Procedures to setup a TE-LSP with Path_Constraints 8 Path_Constraints..........8
6.1. Procedure for the Head-End LSR 8 LSR..............................8
6.2. Procedure for a transit LSR 8
6.3. Procedure for tail-end LSRs 9 transit/tail-end LSR........................8
7. Bi-directional LSPs 9 Procedures for Bidirectional LSPs..........................10
8. Procedures for inter-domain LSPs...........................10
9. IANA Consideration 9
8.1. Consideration.........................................10
9.1. New RSVP C-Num and C-Type 9
8.2. C-Type..................................10
9.2. New LSP Attributes TLV 10
8.3. TLV.....................................10
9.3. New Path Parameters TLV Space 10
8.4. Space:.............................10
9.4. New Error Codes 10
8.5. Codes............................................11
9.5. Security issues 10
9. Intellectual Property Considerations 10 issues............................................11
10. Normative References 11 References.......................................11
11. Informative References 11 References.....................................12
12. Authors' Address 12 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.
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
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 actually two types of TE LSP constraints:
- Link constraints: bandwidth, affinities, etc.
- Spatial Path_Constraints: delay, jitter, hop count, etc.
- Spectral Path Constraints: polarization, signal power, power loss, etc.
Some GMPLS Path_Constraints such as jitter apply only to statistical
multiplexing layers (PSC, L2SC). Some path constraints such as
polarization delay or signal power, applies only hop count apply to photonic layers. any
switching capability. Some other path constraints such as hop count apply only to any a
subset of switching layer. capabilities, such as power loss for instance.
GMPLS Path parameters such as delay, hop count, signal power loss result
from the combination aggregation of link parameters. Their composition can be a
simple accumulation / reduction function but this may be a more
complex function. Such aggregation is
actually an addition of link parameters along the path. For instance
the delay of a path is simply the
accumulation sum of hop delays.
Current Generalized RSVP-TE [RFC3473] signals, and performs local
admission control based on link constraints only. Path_Constraints Path Constraints
are not signaled within RSVP-TE.
However there are in some cases where situations, it would be useful to signal paths
constraints, Paths
Constraints, and combine aggregate link parameters values along the path, in
order to perform an admission control a tail-end LSR, based also on Path_Constraints.
This includes the following cases: 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 constraint, Path Constraints, and combine to aggregate link
parameters along the path, so as to let the tail-end LSRs perform
admission control based on signaled constraints with
respect to the composition of the corresponding and aggregated
link parameter(s). Also it is also useful to reflect actual
aggregated path parameters value back to the Head-End LSR.
- In case of an inter-domain LSP domain context (inter-area, inter-AS) it
may be useful to signal Path_Constraints, and accumulate to aggregate
link parameters, so that a border router can take them into
account when doing ERO expansion (case of per-domain path
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
computation in [INTER-
DOMAIN-COMP]). [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 accumulation for aggregation of link
parameters along the path.
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 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 COMPOSITION AGGREGATION object,
used to build path parameters based on a composition 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, procedures
Encoding and accumulation rules is procedures depend on each path parameter such as
delay, hop count, jitter and LSP class specific 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 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 (in particular during for loose paths), within RSVP-TE, and to combine aggregate
associated link parameters along the path, in order to determine
actual path parameters such as path delay or path hop count. 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
particular value such as
upper or lower bounds for a set of path
parameters or a value range. Values parameters. These values are fixed by
the head-end LSR and are not modified along the path.
A new COMPOSITION RSVP AGGREGATION object is defined so as to compose aggregate link
parameter values along the path and determine end-to-end significant parameters along the path of the
LSP.
parameters. It is updated at each hop, basically each hop combines
received value with its own contribution to the path parameter.
The procedure procedures to signal an LSP with Path_Constraints is are as follows:
- The head-end sends a Path message that includes:
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
- A Path Constraints TLV, included in a LSP_REQUIRED_ATTRIBUTE
object, that encodes for each path constraint carries a set of
parameters. path constraints.
- An COMPOSITION AGGREGATION object that contains a set of path
parameters, initially set to the least significant value.
- At On each transit LSR, LSR along the path, each value included in the COMPOSITION
AGGREGATION 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 Admission control is then performed for each
parameter included in the Path_Constraints TLV. For each
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
parameter, the composed The aggregate
value in the COMPOSITION AGGREGATION object is compared with the path
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 respected then if the tail-end LSR, LSR is at transit
the later sends back a
Resv message, reflecting Path message is propagated downstream and if the COMPOSITION LSR is at
tail-end, the AGGREGATION object that is reflected in a Resv message
and passed unchanged back to the head-end LSR. .
- In case one (or more) constraints are violated, the tail-end LSR
sends back a PathErr message with the Path_State_Removed flag set
Set [RFC3473], and with a new Error code and value that
indicates the violated constraint. The PathErr message also
includes the
COMPOSITION 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. 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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
Value: A set of one or more Path Parameter sub-TLVs
4.2.1. Path Parameter sub-TLV
Each
A path parameter sub-TLV encodes constraint 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:
The 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
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
An LSR that does not recognize a parameter type in the Path
Constraint Constraints TLV or recoginze
it but does not support it MUST reject the Path message using a Path Error with an
Error Code code "Unknown Path Parameter" Attributes TLV" 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 an error value identifying
the processing of this bit will be defined such unknown TLV type code.
An LSR that
it applies to does not recognize a parameter type in the Path
Constraint TLV MUST 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
| |
// Path Parameter Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ break bit for this parameter.
5. The COMPOSITION AGGREGATION object
The COMPOSITION AGGREGATION object is used to build path parameters, by combining
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, with no update at any hop. unchanged.
5.1. Format
The COMPOSITION AGGREGATION object contains a set of Composed Path Parameter TLVs
whose encoding is defined in 2.2.1, each 4.2.1. Each TLV corresponding 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 COMPOSITION AGGREGATION object.
Class = 10bbbbbb, 0bbbbbbb, 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 AGGREGATION object has a C-Num of form 10bbbbbb. 0bbbbbbb. That is, an LSR
that does not recognize this object should discard it silently.
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt reject the LSP and send
back a PathErr with the appropriate error code.
An LSR that recognize this object but does not recognize a path parameter should type in AGGREGATION object
MUST 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. this parameter.
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
6. Procedures to setup a TE-LSP with Path_Constraints Path Constraints
6.1. Procedure for the Head-End LSR
To signal a LSP subject to a set of path_constraints, 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
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 COMPOSITION AGGREGATION Object. In return some path
parameters not subject to admission control may be present in the
COMPOSITION
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 COMPOSITION 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 transit/tail-end LSR
A Transit
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 a COMPOSITION object
received in a Path message, and forward the updated object in the
Path message sent downstream. Basically, for AGGREGATION object. For each path parameter it
should combine has
to accumulate the received value with its own "contribution" to the
parameter. Combination rule depend on If the LSR does not recognize or recognize but does not
support a given path parameter type, and must be
addressed in it should set the document defining break bit of this
parameter to 1.
If the path parameter.
When its local contribution changes, a transit LSR SHOULD send a is at transit it MUST forward the Path message downstream
with an appropriately the updated COMPOSITION AGGREGATION 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.
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 If the LSR is at tail-end it
MUST reflect the COMPOSITION updated AGGREGATION object unchanged in a Resv message upstream sent
back to the head-end LSR.
On receipt of a Path message containing both a COMPOSITION with an AGGREGATION object and a Path_Constraints Path
Constraint TLV in the LSP_REQUIRED_ATTRIBUTE object, the
tail-end 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 an local admission control for each
recognized and supported path parameter constraint included in the Path_Constraints TLV. Each Path
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
Constraints TLV, by verifying that aggregated path parameter
constraint must be compared, 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 accumulated parameter value.
Comparison rules will be addressed in documents defining updated AGGREGATION object and if the path
parameters.
If no constraint LSR
is violated, at tail-end the COMPOSITION updated AGGREGATION object MUST be
reflected unchanged is included in a
Resv message sent upstream. back to the head-end LSR.
- If at least one constraint is violated, then the LSP must MUST be
rejected, and whatever the tail-end LSR must send break bit value and a PathErr message is sent
back to the Head-End LSR with the Path_State_Removed flag set, set
and with a new Error code (path ("path constraint violation, violation"), and error
value corresponding to the TLV type of the violated
constraint. This PathErr message MUST also reflect the COMPOSITION
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.
Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
7. Bi-directional Procedures for Bidirectional LSPs
TBD
8. Procedures for inter-domain LSPs
TBD
9. IANA Consideration
8.1.
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 COMPOSITION AGGREGATION object
The C-Num should be of the form 10bbbbbb 0bbbbbbb so that LSRs that do not
recognize the object will ignore reject the object and discard it silently. LSP.
One C-Type is defined for this object and should be assigned by IANA.
o Path Parameter TLVs
Recommended C-Type value = 1.
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
8.2.
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.
8.3.
9.3. New Path Parameters TLV Space:
The COMPOSITION 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 16-bit 15-bit type identifier (the T-field).
The same T-field values are applicable to the COMPOSITION 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
8.4. of the Path Parameter
- RFC:
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 Violaton" Violation" Identifies the TLV type of the
violated constraint.
8.5.
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].
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.
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 'Key words for use in RFCs to indicate
requirements levels", levels', RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF 'IETF Rights in Contributions", Contributions', BCP 78,
RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., "Intellectual 'Intellectual Property Rights in IETF
Technology",
Technology', BCP 79, RFC 3668, February 2004.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource
'Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification",
Specification', RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V. and G. Swallow, "RSVP-TE: 'RSVP-TE: Extensions
to RSVP for LSP Tunnels", 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 RSVP-TE" draft-ietf-mpls-rsvpte-
attributes, work in Progress,
draft-ietf-mpls-rsvpte-attributes-05.txt, May 2005. progress.
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", RFC 3945, October
2005.
[INTER-DOMAIN-COMP] Vasseur JP., Ayyangar Internet Draft,
Work in Progress, draft-ietf-ccamp-gmpls-architecture-
07.txt, May 2003.
[PD-PATH-COMP] Vasseur, J.P., Ayyangar, A., Zhang Zhang, R., "Inter-
domain MPLS Traffic Engineering LSP " A Per-domain
path
Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt computation methods", (work method for computing Inter-domain
Traffic Engineering (TE) Label Switched Path (LSP)",
draft-ietf-ccamp-inter-domain-pd-path-comp, work in progress).
progress.
12. Authors' Address 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 Intellectual Property Statement
Copyright (C)
The Internet Society (2005). This 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 is subject 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 rights, licenses and restrictions contained procedures with respect to rights in RFC documents can be
found in BCP 78, 78 and
except as set forth therein, BCP 79.
Copies of IPR disclosures made to the authors retain all their rights. 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
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.