idnits 2.17.1 draft-kern-ccamp-rsvpte-hop-attributes-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2009) is 5303 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2205' is defined on line 203, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Kern 3 Internet-Draft A. Takacs 4 Intended status: Standards Track Ericsson 5 Expires: April 22, 2010 October 19, 2009 7 Encoding of Attributes of LSP intermediate hops using RSVP-TE 8 draft-kern-ccamp-rsvpte-hop-attributes-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 22, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 RFC5420 specifies a general framework to support signaling and 47 reporting of generic attributes relevant for a signaled LSP. This 48 document extends the concept and defines a new Explicit Route 49 subobject for RSVP-TE to allow the specification and reporting of 50 attributes relevant to a particular hop of the signaled LSP. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 56 3. HOP_ATTRIBUTES subobject . . . . . . . . . . . . . . . . . . . 5 57 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Processing HOP_ATTRIBUTES subobject . . . . . . . . . . . 5 59 3.2.1. Processing rules for ERO embedding . . . . . . . . . . 5 60 3.2.2. Processing Rules for RRO embedding . . . . . . . . . . 6 61 4. IANA to Consider . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 Generic encoding of LSP attributes is defined in [RFC5420]. It 69 defines two objects: the LSP_ATTRIBUTES and the 70 LSP_REQUIRED_ATTRIBUTES. These two objects are designed to be 71 flexible placeholders in order to carry general LSP related 72 attributes. The content of these new objects are processed by not 73 only the endpoints, but may be interpreted by any intermediate node 74 along the LSP. This procedure allows intermediate nodes to access, 75 extend or modify these attributes. 77 The Explicit Route Object [RFC3209] allows the ingress node to 78 partially or fully specify the route of an LSP. The route is encoded 79 as a sequence of hops that identifies a node or interface that must 80 be crossed. Further attributes assigned to each hop can be added to 81 the route such as per-hop label control [RFC3473] and list of 82 prohibited resources between two nodes [RFC4874]. These additional 83 attributes are inserted into the ERO as subsequent subobjects and are 84 relevant to the preceding hop describing subobject. 86 2. Problem statement 88 [RFC5420] primarily deals with attributes that are relevant to the 89 whole LSP. Currently, it is not possible to declare and signal 90 attributes to a specific intermediate hop of the LSP. 92 There are two straightforward options to signal attributes for 93 intermediate hops: 95 1. Define a new HOP_ATTRIBUTES TLV in the LSP_REQUIRED_ATTRIBUTES 96 Object, where sub-TLVs would identify hops (similarly as in the 97 ERO) and specify attributes for that specific hop. If attributes 98 for multiple hops need to be specified, multiple hop identifying 99 sub-TLVs can be used. 101 2. Introduce a new sub-object in the ERO to carry the attributes of 102 the associated hop specified in the ERO. 104 The first option detaches the encoding of the hop related attributes 105 from route description (from the ERO). This may create problems if 106 for any reason the hops specified in the ERO and the hops identified 107 in the LSP_REQUIRED_ATTRIBUTES Object get mismatched. The second 108 option binds the hop related attributes to the route description 109 avoiding a possible mismatch of cross-references. 111 In this document we introduce (2), i.e, a new ERO sub-object that 112 encodes attributes relevant to a particular internal node or 113 interface of the LSP. To be extensible the objects consist of TLVs. 115 3. HOP_ATTRIBUTES subobject 117 The HOP_ATTRIBUTES subobject can be inserted into route specifying 118 and route recording objects specified for RSVP-TE: Explicit Route 119 Object (ERO)/Secondary Explicit Route Object (SERO) and Record Route 120 Object (RRO)/Secondary Record Route Object (SRRO); and it follows an 121 IPv4 or IPv6 prefix or Unnumbered Interface ID subobject. The 122 carrying object provides the scope of the HOP_ATTRIBUTES subobject as 123 well as processing rules of its content. Regardless the carrying 124 object, content of a HOP_ATTRIBUTES subobject is always relevant to 125 the preceding hop encoding subobject. 127 Note that the HOP_ATTRIBUTES subobject defines a new TLV space that 128 is independent to the TLV space allocated in [RFC5420]. 130 3.1. Format 132 HOP_ATTRIBUTES Type = 0x06 (IANA to assign), same value allocated in 133 ERO and RRO TLV spaces. 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 |0| Type | Length | Reserved | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Attribute TLVs | 141 ~ ~ 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 3.2. Processing HOP_ATTRIBUTES subobject 146 3.2.1. Processing rules for ERO embedding 148 A HOP_ATTRIBUTES subobject follows an IPv4 or IPv6 prefix or 149 Unnumbered Interface ID subobject. The attributes carried in the 150 HOP_ATTRIBUTES subobject is relevant to the associated (preceding) 151 interface or node. 153 A node that does not recognize the type of a TLV carried in the 154 HOP_ATTRIBUTES object must reject the PATH message and issue a 155 PATH_TEAR message with Error Code "Unknown HOP_ATTRIBUTE TLV" and the 156 Error Value is set to the type code of the unknown TLV. 158 When a node recognizes the TLV type code but does not support the 159 attributes of that TLV, it must act according to the document 160 describing the TLV. 162 3.2.2. Processing Rules for RRO embedding 164 An intermediate node may want to notify the endpoints on e.g., hop 165 related status information or values used/selected for specific 166 attributes. In this case the information to be reported is included 167 in a HOP_ATTRIBUTES subobject, which is inserted into the RRO and 168 follows an IPv4 or IPv6 prefix of an Unnumbered Interface ID 169 subobject. 171 4. IANA to Consider 173 o The HOP_ATTRIBUTES subobject can be inserted into any route 174 describing objects specified for RSVP-TE: Explicit Route Object 175 (ERO)/Secondary Explicit Route Object (SERO) and Record Route 176 Object (RRO)/Secondary Record Route Object (SRRO). A new type 177 needs to be assigned for the HOP_ATTRIBUTES subobject, for both 178 the ERO and RRO. The suggested value is 0x06 (IANA to assign). 180 o The HOP_ATTRIBUTES subobject consist of TLVs; a new TLV space is 181 required from which TLVs will be assigned. 183 o A node that does not recognize the type of a TLV carried in the 184 HOP_ATTRIBUTES object must issue a PATH_TEAR message with Error 185 Code "Unknown HOP_ATTRIBUTE TLV" (IANA to assign) and the Error 186 Value is set to the type code of the unknown TLV. 188 5. Security Considerations 190 This document adds a new subobject to Explicit Route, Record Route 191 and Secondary Explicit Route objects. It does not introduce any new 192 direct security issues than listed in [RFC5420]. 194 Any passing node may provide unauthorized access to the attributes 195 relevant to downstream nodes and may alter the attributes. Any 196 passing node may provide unauthorized acces to the attribute or state 197 information reported by any downstram node and may alter them. This 198 document does not provide solution for this issue, that could be 199 handled through encoding and/or digitally signing the objects. 201 6. References 203 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 204 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 205 Functional Specification", RFC 2205, September 1997. 207 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 208 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 209 Tunnels", RFC 3209, December 2001. 211 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 212 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 213 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 215 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 216 Extension to Resource ReserVation Protocol-Traffic 217 Engineering (RSVP-TE)", RFC 4874, April 2007. 219 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 220 Ayyangarps, "Encoding of Attributes for MPLS LSP 221 Establishment Using Resource Reservation Protocol Traffic 222 Engineering (RSVP-TE)", RFC 5420, February 2009. 224 Authors' Addresses 226 Andras Kern 227 Ericsson 228 Laborc u. 1. 229 Budapest, 1037 230 Hungary 232 Email: andras.kern@ericsson.com 234 Attila Takacs 235 Ericsson 236 Laborc u. 1. 237 Budapest, 1037 238 Hungary 240 Email: attila.takacs@ericsson.com