idnits 2.17.1 draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 620. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 2008) is 5632 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-gmpls-ethernet-pbb-te-01 == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-ethernet-traffic-parameters-06 == Outdated reference: A later version (-09) exists of draft-farrel-rtg-common-bnf-07 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-04 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (LabN) 2 Category: Experimental Attila Takacs (Ericsson) 3 Expiration Date: May 17, 2009 Diego Caviglia (Ericsson) 4 Don Fedyk (Nortel) 5 Julien Meuric (France Telecom) 7 November 17, 2008 9 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) 11 draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on May 17, 2009. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document defines a method for the support of GMPLS Asymmetric 45 Bandwidth Bidirectional Label Switched Paths (LSPs). The presented 46 approach is applicable to any switching technology and builds on the 47 original RSVP model for the transport of traffic related parameters. 48 The procedures described in this document are experimental. 50 Table of Contents 52 1 Introduction .............................................. 3 53 1.1 Background ................................................ 3 54 1.2 Approach Overview ......................................... 4 55 1.3 Conventions used in this document ......................... 5 56 2 Generalized Asymmetric Bandwidth Bidirectional LSPs ....... 5 57 2.1 UPSTREAM_FLOWSPEC Object .................................. 5 58 2.1.1 Procedures ................................................ 5 59 2.2 UPSTREAM_TSPEC Object ..................................... 6 60 2.2.1 Procedures ................................................ 6 61 2.3 UPSTREAM_ADSPEC Object .................................... 6 62 2.3.1 Procedures ................................................ 6 63 3 Packet Formats ............................................ 7 64 4 Compatibility ............................................. 8 65 5 IANA Considerations ....................................... 8 66 5.1 UPSTREAM_FLOWSPEC Object .................................. 8 67 5.2 UPSTREAM_TSPEC Object ..................................... 9 68 5.3 UPSTREAM_ADSPEC Object .................................... 9 69 6 Security Considerations ................................... 9 70 7 References ................................................ 9 71 7.1 Normative References ...................................... 9 72 7.2 Informative References .................................... 10 73 8 Authors' Addresses ........................................ 11 74 A. Appendix A: Alternate Approach Using ADSPEC Object ........ 11 75 A.1. Applicability ............................................. 11 76 A.2. Overview .................................................. 12 77 A.3. Procedures ................................................ 13 78 A.4. Compatibility ............................................. 14 79 Full Copyright Statement .................................. 14 80 Intellectual Property ..................................... 14 82 1. Introduction 84 GMPLS, see [RFC3473], introduced explicit support for bidirectional 85 Label Switched Paths (LSPs). The defined support matched the 86 switching technologies covered by GMPLS, notably Time Division 87 Multiplexing (TDM) and lambdas, and specifically only supported 88 bidirectional LSPs with symmetric bandwidth allocation. Symmetric 89 bandwidth requirements are conveyed using the semantics objects 90 defined in [RFC2205] and [RFC2210]. 92 Recent work, see [GMPLS-PBBTE] and [MEF-TRAFFIC], has looked at 93 extending GMPLS to control Ethernet switching. In this context there 94 has been discussion of the support of bidirectional LSPs with 95 asymmetric bandwidth. (That is, bidirectional LSPs that have 96 different bandwidth reservations in each direction.) This discussion 97 motivated the extensions defined in this document, which may be used 98 with any switching technology to signal asymmetric bandwidth 99 bidirectional LSPs. The procedures described in this document are 100 experimental. 102 1.1. Background 104 Bandwidth parameters are transported within RSVP (see [RFC2210], 105 [RFC3209] and [RFC3473]) via several objects that are opaque to RSVP. 106 While opaque to RSVP, these objects support a particular model for 107 the communication of bandwidth information between an RSVP session 108 sender (ingress) and receiver (egress). The original model of 109 communication defined in [RFC2205] and maintained in [RFC3209] used 110 the SENDER_TSPEC and ADSPEC objects in Path messages and the FLOWSPEC 111 object in Resv messages. The SENDER_TSPEC object was used to 112 indicate a sender's data generation capabilities. The FLOWSPEC 113 object was issued by the receiver and indicated the resources that 114 should be allocated to the associated data traffic. The ADSPEC 115 object was used to inform the receiver and intermediate hops of the 116 actual resources allocated for the associated data traffic. 118 With the introduction of bidirectional LSPs in [RFC3473] the model of 119 communication of bandwidth parameters was implicitly changed. In the 120 context of [RFC3473] bidirectional LSPs, the SENDER_TSPEC object 121 indicates the desired resources for both upstream and downstream 122 directions. The FLOWSPEC object is simply confirmation of the 123 allocated resources. The definition of the ADSPEC object is either 124 unmodified, and only has meaning for downstream traffic, or is 125 implicitly or explicitly (see [RFC4606] and [MEF-TRAFFIC]) 126 irrelevant. 128 1.2. Approach Overview 130 The approach for supporting asymmetric bandwidth bidirectional LSPs 131 defined in this document builds on the original RSVP model for the 132 transport of traffic related parameters and GMPLS' support for 133 bidirectional LSPs. An alternative approach was considered and 134 rejected in favor of the more generic approach presented below. For 135 reference purposes only, the rejected approach is summarized in 136 Appendix A. 138 The defined approach is generic and can be applied to any switching 139 technology supported by GMPLS. With this approach, the existing 140 SENDER_TSPEC, ADSPEC and FLOWSPEC objects are complemented with the 141 addition of new UPSTREAM_TSPEC, UPSTREAM_ADSPEC and UPSTREAM_FLOWSPEC 142 objects. The existing objects are used in the original fashion 143 defined in [RFC2205] and [RFC2210], and refer only to traffic 144 associated with the LSP flowing in the downstream direction. The new 145 objects are used in exactly the same fashion as the old objects, but 146 refer to the upstream traffic flow. Figure 1 shows the bandwidth 147 related objects used for Asymmetric Bandwidth Bidirectional LSPs. 149 |---| Path |---| 150 | I |------------------->| E | 151 | n | -SENDER_TSPEC | g | 152 | g | -ADSPEC | r | 153 | r | -UPSTREAM_FLOWSPEC | e | 154 | e | | s | 155 | s | Resv | s | 156 | s |<-------------------| | 157 | | -FLOWSPEC | | 158 | | -UPSTREAM_TSPEC | | 159 | | -UPSTREAM_ADSPEC | | 160 |---| |---| 162 Figure 1: Generic Asymmetric Bandwidth Bidirectional LSPs 164 This extensions defined in this document are limited to P2P LSPs. 165 Support for P2MP bidirectional LSPs is not currently defined and, as 166 such, not covered in this document. 168 1.3. Conventions used in this document 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in [RFC2119]. 174 2. Generalized Asymmetric Bandwidth Bidirectional LSPs 176 The setup of an asymmetric bandwidth bidirectional LSP is signaled 177 using the bidirectional procedures defined in [RFC3473] together with 178 the inclusion of the new UPSTREAM_FLOWSPEC, UPSTREAM_TSPEC and 179 UPSTREAM_ADSPEC objects. 181 The new upstream objects carry the same information and are used in 182 the same fashion as the existing downstream objects; they differ in 183 that they relate to traffic flowing in the upstream direction while 184 the existing objects relate to traffic flowing in the downstream 185 direction. The new objects also differ in that they are used on 186 messages in the opposite directions. 188 2.1. UPSTREAM_FLOWSPEC Object 190 The format of an UPSTREAM_FLOWSPEC object is the same as a FLOWSPEC 191 object. This includes the definition of class types and their 192 formats. The class number of the UPSTREAM_FLOWSPEC object object is 193 TBA by IANA (of the form 0bbbbbbb). 195 2.1.1. Procedures 197 The Path message of an asymmetric bandwidth bidirectional LSP MUST 198 contain an UPSTREAM_FLOWSPEC object and MUST use the bidirectional 199 LSP formats and procedures defined in [RFC3473]. The C-Type of the 200 UPSTREAM_FLOWSPEC Object MUST match the C-Type of the SENDER_TSPEC 201 object used in the Path message. The contents of the 202 UPSTREAM_FLOWSPEC Object MUST be constructed using a format and 203 procedures consistent with those used to construct the FLOWSPEC 204 object that will be used for the LSP, e.g., [RFC2210] or [RFC4328]. 206 Nodes processing a Path message containing an UPSTREAM_FLOWSPEC 207 Object MUST use the contents of the UPSTREAM_FLOWSPEC Object in the 208 upstream label and resource allocation procedure defined in Section 209 3.1 of [RFC3473]. Consistent with [RFC3473], a node that is unable 210 to allocate a label or internal resources based on the contents of 211 the UPSTREAM_FLOWSPEC Object, MUST issue a PathErr message with a 212 "Routing problem/MPLS label allocation failure" indication. 214 2.2. UPSTREAM_TSPEC Object 216 The format of an UPSTREAM_TSPEC object is the same as a SENDER_TSPEC 217 object. This includes the definition of class types and their 218 formats. The class number of the UPSTREAM_TSPEC Object object is TBA 219 by IANA (of the form 0bbbbbbb). 221 2.2.1. Procedures 223 The UPSTREAM_TSPEC object describes the traffic flow that originates 224 at the egress. The UPSTREAM_TSPEC object MUST be included in any 225 Resv message that corresponds to a Path message containing an 226 UPSTREAM_FLOWSPEC object. The C-Type of the UPSTREAM_TSPEC object 227 MUST match the C-Type of the corresponding UPSTREAM_FLOWSPEC object. 228 The contents of the UPSTREAM_TSPEC Object MUST be constructed using a 229 format and procedures consistent with those used to construct the 230 FLOWSPEC object that will be used for the LSP, e.g., [RFC2210] or 231 [RFC4328]. The contents of the UPSTREAM_TSPEC Object MAY differ from 232 contents of the UPSTREAM_FLOWSPEC object based on application data 233 transmission requirements. 235 When an UPSTREAM_TSPEC object is received by an ingress, the ingress 236 MAY determine that the original reservation is insufficient to 237 satisfy the traffic flow. In this case, the ingress MAY issue a Path 238 message with an updated UPSTREAM_FLOWSPEC object to modify the 239 resources requested for the upstream traffic flow. This modification 240 might require the LSP to be re-routed, and in extreme cases might 241 result in the LSP being torn down when sufficient resources are not 242 available. 244 2.3. UPSTREAM_ADSPEC Object 246 The format of an UPSTREAM_ADSPEC object is the same as an ADSPEC 247 object. This includes the definition of class types and their 248 formats. The class number of the UPSTREAM_ADSPEC object is TBA by 249 IANA (of the form 0bbbbbbb). 251 2.3.1. Procedures 253 The UPSTREAM_ADSPEC object MAY be included in any Resv message that 254 corresponds to a Path message containing an UPSTREAM_FLOWSPEC object. 255 The C-Type of the UPSTREAM_TSPEC object MUST be consistent with the 256 C-Type of the corresponding UPSTREAM_FLOWSPEC object. The contents of 257 the UPSTREAM_ADSPEC Object MUST be constructed using a format and 258 procedures consistent with those used to construct the ADSPEC object 259 that will be used for the LSP, e.g., [RFC2210] or [MEF-TRAFFIC]. The 260 UPSTREAM_ADSPEC object is processed using the same procedures as the 261 ADSPEC object and as such, MAY be updated or added at transit nodes. 263 3. Packet Formats 265 This section presents the RSVP message related formats as modified by 266 this section. This document modifies formats defined in [RFC2205], 267 [RFC3209] and [RFC3473]. See [RSVP-BNF] for the syntax used by RSVP. 268 Unmodified formats are not listed. Three new objects are defined in 269 this section: 271 Object name Applicable RSVP messages 272 --------------- ------------------------ 273 UPSTREAM_FLOWSPEC Path, PathTear, PathErr and Notify 274 (via sender descriptor) 275 UPSTREAM_TSPEC Resv, ResvConf, ResvTear, ResvErr and 276 Notify (via flow descriptor list) 277 UPSTREAM_ADSPEC Resv, ResvConf, ResvTear, ResvErr and 278 Notify (via flow descriptor list) 280 The format of the sender description for bidirectional asymmetric 281 LSPs is: 283 ::= 284 [ ] 285 [ ] 286 [ ] 287 [ ] 288 289 291 The format of the flow descriptor list for bidirectional asymmetric 292 LSPs is: 294 ::= 295 | 297 ::= 298 [ ] 299 300