idnits 2.17.1 draft-ietf-teas-network-assigned-upstream-label-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (October 19, 2015) is 3112 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group Vishnu Pavan Beeram (Ed) 3 Internet Draft Juniper Networks 4 Intended status: Standards Track 6 Expires: April 19, 2016 October 19, 2015 8 Network Assigned Upstream-Label 9 draft-ietf-teas-network-assigned-upstream-label-02 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on April 19, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 This document discusses a GMPLS (Generalized Multi-Protocol Label 52 Switching) RSVP-TE (Resource reSerVation Protocol with Traffic 53 Engineering) protocol mechanism that enables the network to assign 54 an upstream label for a bidirectional LSP. This is useful in 55 scenarios where a given node does not have sufficient information to 56 assign the correct upstream label on its own and needs to rely on 57 the downstream node to pick an appropriate label. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC-2119 [RFC2119]. 65 Table of Contents 67 1. Introduction...................................................2 68 2. Use-Case: Alien Wavelength Setup...............................3 69 3. The "Crank-Back" Approach......................................3 70 4. Symmetric Labels...............................................5 71 5. Unassigned Upstream Label......................................5 72 5.1. Processing Rules..........................................5 73 5.2. Backwards Compatibility...................................6 74 6. Applicability..................................................7 75 6.1. Initial Setup.............................................7 76 6.2. Wavelength Change.........................................8 77 7. Security Considerations........................................8 78 8. IANA Considerations............................................8 79 9. References.....................................................9 80 9.1. Normative References......................................9 81 9.2. Informative References....................................9 82 10. Acknowledgments...............................................9 84 1. Introduction 86 The GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE 87 (Resource reSerVation Protocol with Traffic Engineering) extensions 88 for setting up a bidirectional LSP are discussed in [RFC3473]. The 89 bidirectional LSP setup is indicated by the presence of an 90 UPSTREAM_LABEL Object in the PATH message. As per the existing setup 91 procedure outlined for a bidirectional LSP, each upstream node must 92 allocate a valid upstream label on the outgoing interface before 93 sending the initial PATH message downstream. However, there are 94 certain scenarios where it is not desirable or possible for a given 95 node to pick the upstream label on its own. This document defines 96 the protocol mechanism to be used in such scenarios. This mechanism 97 enables a given node to offload the task of assigning the upstream 98 label for a given bidirectional LSP onto the network. 100 2. Use-Case: Alien Wavelength Setup 102 Consider the network topology depicted in Figure 1. Nodes A and B 103 are client IP routers that are connected to an optical WDM transport 104 network. F, H and I represent WDM nodes. The transponder sits on the 105 router and is directly connected to the add-drop port on a WDM node. 107 The optical signal originating on "Router A" is tuned to a 108 particular wavelength. On "WDM-Node F", it gets multiplexed with 109 optical signals at other wavelengths. Depending on the 110 implementation of this multiplexing function, it may not be 111 acceptable to have the router send signal into the optical network 112 unless it is at the appropriate wavelength. In other words, having 113 the router send signal with a wrong wavelength may adversely impact 114 existing optical trails. If the clients do not have full visibility 115 into the optical network, they are not in a position to pick the 116 correct wavelength up-front. 118 | 119 | +---+ /-\ 120 | | | Router ( ) WDM 121 | +---+ Node \-/ node 122 |________________________________ 124 +---+ /-\ /-\ /-\ +---+ 125 | A |---------( F )---------( H )---------( I )---------| B | 126 +---+ \-/ \-/ \-/ +---+ 128 Figure 1: Sample Topology 130 3. The "Crank-Back" Approach 132 There are currently no GMPLS RSVP-TE protocol mechanisms that an 133 upstream node can use for indicating that it does not know what 134 upstream label to use and that it needs the downstream node to pick 135 the label on its behalf. 137 The following setup sequence is an attempt to address the above use- 138 case using the crank-back approach supported by GMPLS RSVP-TE: 140 +---+ /-\ /-\ +---+ 141 | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | 142 +---+ \-/ \-/ +---+ 144 PATH 145 Upstream Label (any available value) 146 ---------------------> 147 PATH-ERR 148 Routing problem/Unacceptable Label Value 149 Acceptable Label Set (L1, L2 .. Ln) 150 <--------------------- 151 PATH 152 Upstream Label (L2) 153 ---------------------> 154 -- ~~ -- ~~ --> 155 PATH 156 --------------------> 157 RESV 158 <-------------------- 159 <-- ~~ -- ~~ -- 160 RESV 161 Label (Assigned) 162 <--------------------- 164 Figure 2: Setup Sequence - Crank-back Approach 166 The above approach does work, but there are a few obvious concerns: 168 - Since "Router-A" does not know which upstream label to use, it 169 picks some random label and signals it without programming its 170 data-plane (this is a deviation from the UPSTREAM_LABEL processing 171 procedures outlined in [RFC3473]). As a result, the outgoing PATH 172 message has no indication of whether the upstream label has been 173 installed along the data-path or not. 174 - If "Router-A" somehow correctly guesses (by sheer luck) an 175 acceptable upstream label upfront, the network may end up finding 176 a path which is suboptimal (there could be a different acceptable 177 upstream label which corresponds to a better path in the network) 178 - The "PATH-ERR with Acceptable Label Set" retry approach is usually 179 used for exception handling. The above solution uses it for almost 180 every single setup request (except in the rare scenario where the 181 appropriate upstream label is guessed correctly). 182 - There is an awkward window between the time the network sends out 183 the PATH-ERR message (with the ACCEPTABLE_LABEL_SET) and receives 184 the corresponding PATH message (with the selected UPSTREAM_LABEL); 185 this window opens up the possibility of the selected 186 UPSTREAM_LABEL to be stale by the time the network receives the 187 retry PATH. 188 - The above solution assumes the use of "symmetric labels" by 189 default. 191 The rest of the sections in this draft present a solution proposal 192 that is devoid of any of the above concerns. 194 4. Symmetric Labels 196 As per [RFC3471], the upstream label and the downstream label for an 197 LSP at a given hop need not be the same. The use-case discussed in 198 this document pertains to Lambda Switch Capable (LSC) LSPs and it is 199 an undocumented fact that in practice, LSC LSPs always have 200 symmetric labels at each hop along the path of the LSP. 202 The use of the protocol mechanism discussed in this document 203 mandates "Label Symmetry". This mechanism is meant to be used only 204 for bidirectional LSPs that assign symmetric labels at each hop 205 along the path of the LSP. 207 5. Unassigned Upstream Label 209 This document proposes the use of a special label value - 210 "0xFFFFFFFF" - to indicate an Unassigned Upstream Label. The 211 presence of this value in the UPSTREAM_LABEL object of a PATH 212 message indicates that the upstream node has not assigned an 213 upstream label on its own and has requested the downstream node to 214 provide a label that it can use in both forward and reverse 215 directions. The presence of this value in the UPSTREAM_LABEL object 216 of a PATH message MUST also be interpreted by the receiving node as 217 a request to mandate "symmetric labels" for the LSP. 219 5.1. Processing Rules 221 The Unassigned Upstream Label is used by an upstream node when it is 222 not in a position to pick the upstream label on its own. In such a 223 scenario, the upstream node sends a PATH message downstream with an 224 Unassigned Upstream Label and requests the downstream node to 225 provide a symmetric label. If the upstream node desires to make the 226 downstream node aware of its limitations with respect to label 227 selection, it MUST specify a list of valid labels via the LABEL_SET 228 object as specified in [RFC3473]. 230 In response, the downstream node picks an appropriate symmetric 231 label and sends it via the LABEL object in the RESV message. The 232 upstream node would then start using this symmetric label for both 233 directions of the LSP. If the downstream node cannot pick the 234 symmetric label, it MUST issue a PATH-ERR message with a "Routing 235 Problem/Unacceptable Label Value" indication. 237 The upstream node will continue to signal the Unassigned Upstream 238 Label in the PATH message even after it receives an appropriate 239 symmetric label in the RESV message. This is done to make sure that 240 the downstream node would pick a different symmetric label if and 241 when it needs to change the label at a later point in time. 243 +----------+ +------------+ 244 ---| Upstream |--------------------| Downstream |--- 245 +----------+ +------------+ 247 PATH 248 Upstream Label (Unassigned) 249 Label-Set (L1, L2 ... Ln) 250 -------------------> 252 RESV 253 Label (Assigned - L2) 254 <------------------- 256 Figure 3: Unassigned UPSTREAM_LABEL 258 5.2. Backwards Compatibility 260 If the downstream node is running an older implementation and 261 doesn't understand the semantics of an Unassigned UPSTREAM LABEL, it 262 will either (a) reject the special label value and generate an error 263 as specified in Section 3.1 of [RFC3473] or (b) accept it and treat 264 it as a valid label. 266 If the behavior that is exhibited is (a), then there are obviously 267 no backwards compatibility concerns. If there is some existing 268 implementation that exhibits the behavior in (b), then there could 269 be some potential issues. However, at the time of publication, there 270 is no documented evidence of any existing implementation that uses 271 0xFFFFFFFF as a valid label. Thus, it is safe to assume that the 272 behavior in (b) will never be exhibited. 274 6. Applicability 276 The use-case discussed in Section 2 is revisited to examine how the 277 mechanism proposed in this document allows the optical network to 278 select and communicate the correct wavelength to its clients. 280 6.1. Initial Setup 282 +---+ /-\ /-\ +---+ 283 | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | 284 +---+ \-/ \-/ +---+ 286 PATH 287 Upstream Label (Unassigned/0xFFFFFFFF) 288 ---------------------> 289 -- ~~ -- ~~ --> 290 PATH 291 --------------------> 292 RESV 293 <-------------------- 294 <-- ~~ -- ~~ -- 295 RESV 296 Label (Assigned) 297 <--------------------- 299 Figure 4: Alien Wavelength - Initial Setup 301 Steps: 302 - "Router A" does not have enough information to pick an 303 appropriate client wavelength. It sends a PATH message 304 downstream requesting the network to assign an appropriate 305 symmetric label for its use. Since the client wavelength is 306 unknown, the laser is off at the ingress client. 307 - The downstream node (Node F) receives the PATH message, chooses 308 the appropriate wavelength values and forwards them in 309 appropriate label fields to the egress client ("Router B") 310 - "Router B" receives the PATH message, turns the laser ON and 311 tunes it to the appropriate wavelength (received in the 312 UPSTREAM_LABEL/LABEL_SET of the PATH) and sends out a RESV 313 message upstream. 315 - The RESV message received by the ingress client carries a valid 316 symmetric label in the LABEL object. "Router A" turns on the 317 laser and tunes it to the wavelength specified in the network 318 assigned symmetric LABEL. 320 For cases where the egress-node relies on RSVP signaling to 321 determine exactly when to start using the LSP, this draft recommends 322 integrating the above sequence with any of the existing graceful 323 setup procedures: 324 - "RESV-CONF" setup procedure (or) 325 - 2-step "ADMIN STATUS" based setup procedure ("A" bit set in the 326 first step; "A" bit cleared when the LSP is ready for use). 328 6.2. Wavelength Change 330 After the LSP is set up, the network MAY decide to change the 331 wavelength for the given LSP. This could be for a variety of reasons 332 - policy reasons, restoration within the core, preemption etc. 334 In such a scenario, if the ingress client receives a changed label 335 via the LABEL object in a RESV modify, it MUST retune the laser at 336 the ingress to the new wavelength. Similarly if the egress client 337 receives a changed label via UPSTREAM_LABEL/LABEL_SET in a PATH 338 modify, it MUST retune the laser at the egress to the new 339 wavelength. If the node receiving the changed label in a PATH/RESV 340 message does not find the label acceptable, then the corresponding 341 error procedures defined in [RFC3473] MUST be followed. 343 7. Security Considerations 345 This document defines a special label value to be carried in the 346 UPSTREAM_LABEL object of a PATH message. This special label value is 347 used to enable the function of requesting network assignment of an 348 upstream label. The changes proposed in this document pertain to the 349 semantics of a specific field in an existing RSVP object and the 350 corresponding procedures. Thus, there are no new security 351 implications raised by this document. 353 For a general discussion on MPLS and GMPLS related security issues, 354 see the MPLS/GMPLS security framework [RFC5920]. 356 8. IANA Considerations 358 This document makes no requests for IANA action. 360 9. References 362 9.1. Normative References 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, March 1997. 367 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 368 Signaling Functional Description", RFC 3471, January 369 2003 371 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 372 Signaling Resource Reservation Protocol-Traffic 373 Engineering Extensions", RFC 3473, January 2003. 375 9.2. Informative References 377 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 378 Networks", RFC 5920, July 2010. 380 10. Acknowledgments 382 The authors would like to thank Adrian Farrel and Chris Bowers for 383 their inputs. 385 Authors' Addresses 387 Vishnu Pavan Beeram 388 Juniper Networks 389 Email: vbeeram@juniper.net 391 John Drake 392 Juniper Networks 393 Email: jdrake@juniper.net 395 Gert Grammel 396 Juniper Networks 397 Email: ggrammel@juniper.net 399 Igor Bryskin 400 ADVA Optical Networking 401 Email: ibryskin@advaoptical.com 402 Pawel Brzozowski 403 ADVA Optical Networking 404 Email: pbrzozowski@advaoptical.com 406 Daniele Ceccarelli 407 Ericsson 408 Email: daniele.ceccarelli@ericsson.com 410 Oscar Gonzalez de Dios 411 Telefonica 412 Email: ogondio@tid.es 414 Zafar Ali 415 Cisco Systems, Inc. 416 Email: zali@cisco.com 418 Xian Zhang 419 Huawei Technologies 420 Email: zhang.xian@huawei.com