[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00
Network Working Group A. Kern
Internet-Draft A. Takacs
Intended status: Standards Track Ericsson
Expires: April 22, 2010 October 19, 2009
Encoding of Attributes of LSP intermediate hops using RSVP-TE
draft-kern-ccamp-rsvpte-hop-attributes-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 22, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Kern & Takacs Expires April 22, 2010 [Page 1]
Internet-Draft Attributes for LSP hops Using RSVP-TE October 2009
Abstract
RFC5420 specifies a general framework to support signaling and
reporting of generic attributes relevant for a signaled LSP. This
document extends the concept and defines a new Explicit Route
subobject for RSVP-TE to allow the specification and reporting of
attributes relevant to a particular hop of the signaled LSP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4
3. HOP_ATTRIBUTES subobject . . . . . . . . . . . . . . . . . . . 5
3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Processing HOP_ATTRIBUTES subobject . . . . . . . . . . . 5
3.2.1. Processing rules for ERO embedding . . . . . . . . . . 5
3.2.2. Processing Rules for RRO embedding . . . . . . . . . . 6
4. IANA to Consider . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Kern & Takacs Expires April 22, 2010 [Page 2]
Internet-Draft Attributes for LSP hops Using RSVP-TE October 2009
1. Introduction
Generic encoding of LSP attributes is defined in [RFC5420]. It
defines two objects: the LSP_ATTRIBUTES and the
LSP_REQUIRED_ATTRIBUTES. These two objects are designed to be
flexible placeholders in order to carry general LSP related
attributes. The content of these new objects are processed by not
only the endpoints, but may be interpreted by any intermediate node
along the LSP. This procedure allows intermediate nodes to access,
extend or modify these attributes.
The Explicit Route Object [RFC3209] allows the ingress node to
partially or fully specify the route of an LSP. The route is encoded
as a sequence of hops that identifies a node or interface that must
be crossed. Further attributes assigned to each hop can be added to
the route such as per-hop label control [RFC3473] and list of
prohibited resources between two nodes [RFC4874]. These additional
attributes are inserted into the ERO as subsequent subobjects and are
relevant to the preceding hop describing subobject.
Kern & Takacs Expires April 22, 2010 [Page 3]
Internet-Draft Attributes for LSP hops Using RSVP-TE October 2009
2. Problem statement
[RFC5420] primarily deals with attributes that are relevant to the
whole LSP. Currently, it is not possible to declare and signal
attributes to a specific intermediate hop of the LSP.
There are two straightforward options to signal attributes for
intermediate hops:
1. Define a new HOP_ATTRIBUTES TLV in the LSP_REQUIRED_ATTRIBUTES
Object, where sub-TLVs would identify hops (similarly as in the
ERO) and specify attributes for that specific hop. If attributes
for multiple hops need to be specified, multiple hop identifying
sub-TLVs can be used.
2. Introduce a new sub-object in the ERO to carry the attributes of
the associated hop specified in the ERO.
The first option detaches the encoding of the hop related attributes
from route description (from the ERO). This may create problems if
for any reason the hops specified in the ERO and the hops identified
in the LSP_REQUIRED_ATTRIBUTES Object get mismatched. The second
option binds the hop related attributes to the route description
avoiding a possible mismatch of cross-references.
In this document we introduce (2), i.e, a new ERO sub-object that
encodes attributes relevant to a particular internal node or
interface of the LSP. To be extensible the objects consist of TLVs.
Kern & Takacs Expires April 22, 2010 [Page 4]
Internet-Draft Attributes for LSP hops Using RSVP-TE October 2009
3. HOP_ATTRIBUTES subobject
The HOP_ATTRIBUTES subobject can be inserted into route specifying
and route recording objects specified for RSVP-TE: Explicit Route
Object (ERO)/Secondary Explicit Route Object (SERO) and Record Route
Object (RRO)/Secondary Record Route Object (SRRO); and it follows an
IPv4 or IPv6 prefix or Unnumbered Interface ID subobject. The
carrying object provides the scope of the HOP_ATTRIBUTES subobject as
well as processing rules of its content. Regardless the carrying
object, content of a HOP_ATTRIBUTES subobject is always relevant to
the preceding hop encoding subobject.
Note that the HOP_ATTRIBUTES subobject defines a new TLV space that
is independent to the TLV space allocated in [RFC5420].
3.1. Format
HOP_ATTRIBUTES Type = 0x06 (IANA to assign), same value allocated in
ERO and RRO TLV spaces.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2. Processing HOP_ATTRIBUTES subobject
3.2.1. Processing rules for ERO embedding
A HOP_ATTRIBUTES subobject follows an IPv4 or IPv6 prefix or
Unnumbered Interface ID subobject. The attributes carried in the
HOP_ATTRIBUTES subobject is relevant to the associated (preceding)
interface or node.
A node that does not recognize the type of a TLV carried in the
HOP_ATTRIBUTES object must reject the PATH message and issue a
PATH_TEAR message with Error Code "Unknown HOP_ATTRIBUTE TLV" and the
Error Value is set to the type code of the unknown TLV.
When a node recognizes the TLV type code but does not support the
attributes of that TLV, it must act according to the document
describing the TLV.
Kern & Takacs Expires April 22, 2010 [Page 5]
Internet-Draft Attributes for LSP hops Using RSVP-TE October 2009
3.2.2. Processing Rules for RRO embedding
An intermediate node may want to notify the endpoints on e.g., hop
related status information or values used/selected for specific
attributes. In this case the information to be reported is included
in a HOP_ATTRIBUTES subobject, which is inserted into the RRO and
follows an IPv4 or IPv6 prefix of an Unnumbered Interface ID
subobject.
Kern & Takacs Expires April 22, 2010 [Page 6]
Internet-Draft Attributes for LSP hops Using RSVP-TE October 2009
4. IANA to Consider
o The HOP_ATTRIBUTES subobject can be inserted into any route
describing objects specified for RSVP-TE: Explicit Route Object
(ERO)/Secondary Explicit Route Object (SERO) and Record Route
Object (RRO)/Secondary Record Route Object (SRRO). A new type
needs to be assigned for the HOP_ATTRIBUTES subobject, for both
the ERO and RRO. The suggested value is 0x06 (IANA to assign).
o The HOP_ATTRIBUTES subobject consist of TLVs; a new TLV space is
required from which TLVs will be assigned.
o A node that does not recognize the type of a TLV carried in the
HOP_ATTRIBUTES object must issue a PATH_TEAR message with Error
Code "Unknown HOP_ATTRIBUTE TLV" (IANA to assign) and the Error
Value is set to the type code of the unknown TLV.
Kern & Takacs Expires April 22, 2010 [Page 7]
Internet-Draft Attributes for LSP hops Using RSVP-TE October 2009
5. Security Considerations
This document adds a new subobject to Explicit Route, Record Route
and Secondary Explicit Route objects. It does not introduce any new
direct security issues than listed in [RFC5420].
Any passing node may provide unauthorized access to the attributes
relevant to downstream nodes and may alter the attributes. Any
passing node may provide unauthorized acces to the attribute or state
information reported by any downstram node and may alter them. This
document does not provide solution for this issue, that could be
handled through encoding and/or digitally signing the objects.
Kern & Takacs Expires April 22, 2010 [Page 8]
Internet-Draft Attributes for LSP hops Using RSVP-TE October 2009
6. References
[RFC2205] Braden, B., 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.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009.
Kern & Takacs Expires April 22, 2010 [Page 9]
Internet-Draft Attributes for LSP hops Using RSVP-TE October 2009
Authors' Addresses
Andras Kern
Ericsson
Laborc u. 1.
Budapest, 1037
Hungary
Email: andras.kern@ericsson.com
Attila Takacs
Ericsson
Laborc u. 1.
Budapest, 1037
Hungary
Email: attila.takacs@ericsson.com
Kern & Takacs Expires April 22, 2010 [Page 10]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/