Internet DRAFT - draft-farrel-mpls-rsvpte-attributes
draft-farrel-mpls-rsvpte-attributes
Network Working Group Adrian Farrel
Internet Draft Old Dog Consulting
Category: Standards Track
Expires: April 2004 Dimitri Papadimitriou
Alcatel
Jean-Philippe Vasseur
Cisco Systems, Inc.
October 2003
Encoding of Attributes for Multiprotocol Label Switching (MPLS)
Label Switched Path (LSP) Establishment Using RSVP-TE
draft-farrel-mpls-rsvpte-attributes-00.txt
Status of this Memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC 2026
[RFC2026].
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.
Abstract
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may
be established using the Resource Reservation Protocol Traffic
Engineering extensions (RSVP-TE). This protocol includes an object
(the SESSION_ATTRIBUTE object) which carries a flags field used to
indicate options and attributes of the LSP. That flags field has
eight bits allowing for eight options to be set.
Recent proposals in many documents that extend RSVP-TE for signaling
additional features and function for MPLS LSPs have suggested uses
for each of the previously unused bits.
This document defines a new object for RSVP-TE messages that allows
the signaling of further attribute bits and also the carriage of
arbitrary attribute parameters. This makes RSVP-TE easily extensible
to support new requirements.
Farrel, Papadimitriou and Vasseur Page 1
draft-farrel-mpls-rsvpte-attributes-00.txt October 2003
1. Introduction and Problem Statement
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
[RFC3031] may be established using the RSVP-TE signaling protocol
[RFC3209]. This protocol uses the Path message to request that a LSP
be set up. The Path message includes the SESSION_ATTRIBUTE object
which carries a flags field used to indicate desired options and
attributes of the LSP.
The flags field in the SESSION_ATTRIBUTE object has eight bits. Just
three of those bits are assigned in [RFC3209]. A further two bits are
assigned in [FRR] for fast re-reroute functionality leaving only
three bits available. Several recent proposals and Internet Drafts
have demonstrated that there is a high demand for the use of the
other three bits. Some, if not all, of those proposals are likely to
go forward as RFCs resulting in depletion or near depletion of the
flags field and a consequent difficulty in signaling new options and
attributes that may be developed in the future.
This document defines a new object for RSVP-TE messages that allows
the signaling of further attributes bits. The new object is
constructed from TLVs, and a new TLV is defined to carry up to thirty
two new attributes bits. Because of the nature of the TLV
construction the object is flexible and allows the future definition
of:
- further sets of thirty two bits if more flags are needed to carry
yet more attributes
- arbitrary options and attributes parameters carried as individual
TLVs.
It is noted that that some options and attributes do not need to be
acted on by all Label Switched Routers (LSRs) along the path of the
LSP. In particular, these options and attributes may apply only to
key LSRs on the path such as the ingress and egress. Special transit
LSRs, such as AS Border Routers (ASBRs) may also fall into this
category. This means that the new options and attributes should be
signaled transparently, and only examined at those points that need
to act on them.
On the other hand, other options and attributes may require action
at all transit LSRs along the path of the LSP. Inability to support
the required attributes by one of those transit LSRs may require the
LSR to refuse the establishment of the LSP.
These considerations are particularly important in the context
backwards compatibility. In general, it should be possible to provide
new MPLS services across a legacy network without upgrading those
LSRs that do not need to participate actively in the new services.
RSVP includes a way for unrecognized objects to be forwarded by
transit nodes without them refusing the protocol message and with the
objects being stripped from the protocol message (see [RFC2205]
section 3.10). This extends to RSVP-TE and provides a good way to
ensure that only those LSRs that understand a particular object
examine it.
Farrel, Papadimitriou and Vasseur Page 2
draft-farrel-mpls-rsvpte-attributes-00.txt October 2003
This document distinguishes between options and attributes that are
only required at key LSRs along the path of the LSP, and those that
must be acted on by every LSR along the LSP. Two LSP Attributes
objects are defined in this document: the first may be passed
transparently by LSRs that do not recognize it, the second must cause
LSP setup failure with the generation of a PathErr message if an LSR
does not recognize it.
Comments on this document should be made direct to the MPLS mailing
list at mpls@uu.net.
1.1 Applicability to Generalized MPLS
The RSVP-TE signaling protocol also forms the basis of a signaling
protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and
[RFC3473]. The extensions described in this document are intended to
be equally applicable to MPLS and GMPLS.
1.2 A Rejected Alternate Solution
A rejected alternate solution was to define a new C-Type for the
existing SESSION_ATTRIBUTE object. This new C-Type could allow a
larger Flags field and address the immediate problem.
This solution was rejected because:
- A C-Type is not backward compatible with deployed implementations
that expect to see a C-Type of 1 or 7. It is important that any
solution be capable of carrying new attributes transparently
across legacy LSRs if those LSRs are not required to act on the
attributes.
- Support for arbitrary attributes parameters through TLVs would
have meant a significant change of substance to the existing
object.
1.3 Protocol Developments Without an Explicit Need
[This section to be removed if this draft proceeds towards an RFC.
References in this section are not intended to be normative.]
It is unusual and inadvised for the IETF to accept a speculative
change to a protocol without an explicit need. That is, in this case,
although there is an obvious problem identified, there is no existing
Working Group proposal that requires further option bits. For today,
the existing protocol objects are adequate.
There are, however, several Internet Drafts that propose additional
attributes associated with LSP setup. These include [CRANKBACK],
[REOPT] and [INTER-AS]. In view of the likelihood of one or more of
these drafts advancing to RFC, and considering the probable
requirement to be able to signal further options and attributes for
other purposes in the very near future, it is proposed that this
document be debated within the MPLS Working Group so that a solution
will be available should the need arise.
Farrel, Papadimitriou and Vasseur Page 3
draft-farrel-mpls-rsvpte-attributes-00.txt October 2003
Further, the lack of a considered approach to handle the shortage of
SESSION_ATTRIBUTE flags might give rise to a range of diverse
solutions each developed within the context of a single protocol
extension. Clearly a single coherent solution is better.
[This section to be removed if this draft proceeds towards an RFC.]
2. 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].
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 RFC2119 [6].
3. Attributes TLVs
Attributes carried by the new objects defined in this document are
encoded within TLVs. One or more TLVs may be present in each object.
There are no ordering rules for TLVs and no interpretation should be
placed on the order in which TLVs are received.
Each 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
The identifier of the TLV.
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.
Value
The data for the TLV padded as described above.
Farrel, Papadimitriou and Vasseur Page 4
draft-farrel-mpls-rsvpte-attributes-00.txt October 2003
3.1 Attributes Flags TLV
This document defines only one TLV type value. Type 1 indicates the
Attributes Flags TLV. Other TLV types may be defined in future with
type values assigned by IANA.
The Attributes Flags TLV value field is a 32 bit array of flags
numbered from the MSB as bit zero. The length field for this TLV is
set to 4.
Unassigned bits are considered as reserved and MUST be set to zero
on transmission and ignored on receipt.
No bits are defined in this document. The assignment of bits is
managed by IANA.
4. LSP_ATTRIBUTES Object
The LSP_ATTRIBUTES object is used to signal attributes required in
support of an LSP, or to indicate the nature or use of an LSP where
that information is not required to be acted on by all transit LSRs.
Specifically, if an LSR does not support the object, it forwards it
unexamined and unchanged. This facilitates the exchange of attributes
across legacy networks that do not support this new object.
This object effectively extends the flags field in the SESSION_
ATTRIBUTE object and allows for the future inclusion of more complex
objects through TLVs.
The LSP_ATTRIBUTES object class is TBD of the form 11bbbbbb. This
C-Num value (see section 7) ensures that LSRs that do not recognize
the object pass it on transparently.
One C-Type is defined, C-Type = 1 for LSP Attributes.
This object is optional and may be placed on Path messages to convey
additional information about the desired attributes of the LSP.
4.1 Format
LSP_ATTRIBUTES class = TBD, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attributes TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attributes TLVs are encoded as described in section 3.
Farrel, Papadimitriou and Vasseur Page 5
draft-farrel-mpls-rsvpte-attributes-00.txt October 2003
4.2 Generic Processing Rules
An LSR that does not support this object will pass it on unaltered
because of the C-Num.
An LSR that does support this object, but does not recognize a TLV
type code carried in this object, or recognizes the TLV but does not
support the attribute MUST act as specified in the document that
defines the TLV.
An LSR that supports the Attributes Flags TLV, but does not
recognize a bit set in the Attributes Flags TLV MUST forward the
object unchanged.
An LSR that supports the Attributes Flags TLV and recognizes a bit
that is set but does not support the indicated attribute MUST act as
specified in the document that defines the bit.
5. LSP_REQUIRED_ATTRIBUTES Object
The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes
required in support of a LSP, or to indicate the nature or use of
a LSP where that information MUST be inspected at each transit LSR.
Specifically, each transit LSR MUST examine the attributes in the
LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object
transparently.
This object effectively extends the flags field in the SESSION_
ATTRIBUTE object and allows for the future inclusion of more complex
objects through TLVs. It complements the LSP_ATTRIBUTES object.
The LSP_REQUIRED_ATTRIBUTES object class is TBD of the form 0bbbbbbb.
This C-Num value (see section 7) ensures that LSRs that do not
recognize the object reject the LSP setup effectively saying that
they do not support the attributes requested. This means that this
object should only be used for attributes that require support at
some transit LSRs and so require examination at all transit LSRs. See
section 4 for how end-to-end and selective attributes are signaled.
One C-Type is defined, C-Type = 1 for LSP Required Attributes.
This object is optional and may be placed on Path messages to convey
additional information about the desired attributes of the LSP.
5.1 Format
LSP_REAQUIRED_ATTRIBUTES class = TBD, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attributes TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attributes TLVs are encoded as described in section 3.
Farrel, Papadimitriou and Vasseur Page 6
draft-farrel-mpls-rsvpte-attributes-00.txt October 2003
5.2 Generic Processing Rules
An LSR that does not support this object will use a PathErr to reject
the Path message based on the C-Num using the error code "Unknown
Object Class".
An LSR that does not recognize a TLV type code carried in this object
MUST reject the Path message using a PathErr with Error Code
"Unknown Attributes TLV" and Error Value set to the value of the
unknown TLV type code.
An LSR that does not recognize a bit set in the Attributes Flags
TLV MUST reject the Path message using a PathErr with Error Code
"Unknown Attributes Bit" and Error Value set to the bit number of
the unknown bit in the Attributes Flags (that is a number between 0
and 32).
An LSR that recognizes an attribute, however encoded, but which does
not support that attribute MUST act according to the behavior
specified in the document that defines that specific attribute.
6. Message Formats
The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object MAY
be carried in a Path message.
The order of objects in RSVP-TE messages is recommended, but
implementations must be capable of receiving the objects in any
meaningful order. The LSP_ATTRIBUTES object and LSP_REQUIRED_
ATTRIBUTES objects are RECOMMENDED to be placed immediately after the
SESSION_ATTRIBUTE object if it is present, or otherwise immediately
after the LABEL_REQUEST object.
If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES
object are present, the LSP_REQUIRED_ATTRIBUTES object is RECOMMENDED
to be placed first.
LSRs should be prepared to receive these objects in any order in any
position within a Path message. Subsequent instances of these objects
within a Path message SHOULD be ignored.
7. IANA Considerations
7.1 New RSVP C-Nums and C-Types
Two new RSVP C-Nums are defined in this document and should be
assigned by IANA.
o LSP_ATTRIBUTES object
The C-Num 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 resulting from this
message.
Farrel, Papadimitriou and Vasseur Page 7
draft-farrel-mpls-rsvpte-attributes-00.txt October 2003
One C-Type is defined for this object and should be assigned by
IANA.
o LSP Attributes TLVs
Recommended C-Type value 1.
o LSP_REQUIRED_ATTRIBUTES object
The C-Num should be of the form 0bbbbbbb so that LSRs that do not
recognize the object will reject the message that carries it with
an "Unknown Object Class" error.
One C-Type is defined for this object and should be assigned by
IANA.
o LSP Required Attributes TLVs
Recommended C-Type value 1.
7.2 New TLV Space
The two new objects referenced above are constructed from TLVs. Each
TLV includes a 16-bit type identifier (the T-field). The same T-field
values are applicable to both objects.
IANA is requested to manage the space of TLV type identifiers as
follows:
- TLV Type
- TLV Name
- Whether allowed on LSP_ATTRIBUTES object
- Whether allowed on LSP_REQUIRED_ATTRIBUTES object.
This document defines one TLV type as follows:
- TLV Type = 1
- TLV Name = LSP Attributes Flags
- allowed on LSP_ATTRIBUTES object
- allowed on LSP_REQUIRED_ATTRIBUTES object.
7.3 Attributes Flags
This document provides 32 new attributes bit flags for use in other
documents that specify new RSVP-TE attributes. These flags are
present in the LSP Attributes Flags TLV referenced in the previous
section.
IANA is requested to manage the space of attributes bit flags
numbering them in the usual IETF notation starting at zero.
7.4 SESSION_ATTRIBUTE Flags Field
This document does not make any alterations to the definition of the
existing SESSION_ATTRIBUTE object nor to the definition of meanings
assigned to the flags in the Flags field of that object. These flags
are assigned meanings in various other RFCs and Internet Drafts.
Farrel, Papadimitriou and Vasseur Page 8
draft-farrel-mpls-rsvpte-attributes-00.txt October 2003
It is suggested that IANA manage the allocation of meaning to the
bits in the Flags field of the SESSION_ATTRIBUTE object to prevent
accidental double allocation of any one bit.
7.5 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 Attributes TLV" Identifies the unknown TLV type code.
"Unknown Attributes Bit" Identifies the unknown Attribute Bit.
8. Security Considerations
This document adds two new objects to the RSVP Path message as used
in MPLS and GMPLS signaling. It does not introduce any new direct
security issues and the reader is referred to the security
considerations expressed in [RFC2205], [RFC3209] and [RFC3473].
It is of passing note that any signaling request that indicates the
functional preferences or attributes of an MPLS LSP may provide
anyone with unauthorized access to the contents of the message with
information about the LSP that an administrator may wish to keep
secret. Although this document adds new objects for signaling desired
LSP attributes, it does not contribute to this issue which can
only be satisfactorily handled by encrypting the content of the
signaling message.
9. Acknowledgements
Credit to the OSPF Working Group for inspiration from their solution
to a similar problem.
Thanks to Rahul Aggarwal for his careful review and support of this
work. Thanks also to Raymond Zhang for his input.
10. Intellectual Property Consideration
The IETF takes no position regarding the validity or scope
of any intellectual property 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; neither does it represent that it has made any
effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track
and standards-related documentation can be found in BCP-11.
Copies of claims of rights made available for publication
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
implementors or users of this specification can be obtained
from the IETF Secretariat.
Farrel, Papadimitriou and Vasseur Page 9
draft-farrel-mpls-rsvpte-attributes-00.txt October 2003
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may
be required to practice this standard. Please address the
information to the IETF Executive Director.
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S.
and S. Jamin, "Resource ReserVation Protocol --
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.
[FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for
LSP Tunnels", <draft-ietf-mpls-rsvp-lsp-fastreroute-03
.txt>, Internet Draft, work in progress.
12. Informative References
[RFC2026] Bradner, S., "The Internet Standards Process
-- Revision 3", RFC 2026, October 1996.
[RFC3031] Rosen, E., Viswanathan, A., and Callon, R.,
"Multiprotocol Label Switching
Architecture", RFC 3031, January 2001.
[INTER-AS] Vasseur, JP., Zhang, R., "Inter-AS MPLS Traffic
Engineering", <draft-vasseur-inter-as-te-01.txt>,
Internet Draft, work in progress.
[OSPF-CAPS] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S.,
Vasseur, JP., "Extensions to OSPF for Advertising
Optional Router Capabilities", <draft-ietf-ospf-cap-
00.txt>, Internet Draft, work in progress.
[REOPT] Vasseur, JP., Ikejiri, Y., "Reoptimization of MPLS
Traffic Engineering loosely routed explicit LSP path",
<draft-vasseur-mpls-loose-path-reopt-02.txt>, Internet
Draft, work in progress.
Farrel, Papadimitriou and Vasseur Page 10
draft-farrel-mpls-rsvpte-attributes-00.txt October 2003
13. Authors' Addresses
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Dimitri Papadimitriou (Alcatel)
Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Jean Philippe Vasseur
Cisco Systems, Inc.
300 Apollo Drive
Chelmsford, MA 01824
300 Beaver Brook Road
Boxborough , MA - 01719
USA
Email: jpv@cisco.com
14. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implementation may
be prepared, copied, published and distributed, in whole or
in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on
all such copies and derivative works. However, this
document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns. This document and the information
contained herein is provided on an "AS IS" basis and THE
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS 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.
Farrel, Papadimitriou and Vasseur Page 11
