idnits 2.17.1 draft-ietf-teas-network-assigned-upstream-label-04.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 (March 11, 2017) is 2602 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 X. Zhang, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track V. Beeram, Ed. 5 Expires: September 12, 2017 Juniper Networks 6 I. Bryskin 7 Huawei Technologies 8 D. Ceccarelli 9 Ericsson 10 O. Gonzalez de Dios 11 Telefonica 12 March 11, 2017 14 Network Assigned Upstream-Label 15 draft-ietf-teas-network-assigned-upstream-label-04 17 Abstract 19 This document discusses a Generalized Multi-Protocol Label Switching 20 (GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP- 21 TE) mechanism that enables the network to assign an upstream label 22 for a bidirectional LSP. This is useful in scenarios where a given 23 node does not have sufficient information to assign the correct 24 upstream label on its own and needs to rely on the downstream node to 25 pick an appropriate label. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 12, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2. Use-Case: Wavelength Setup for IP over Optical Networks . . . 3 64 3. The "Crankback Signaling" Approach . . . . . . . . . . . . . 3 65 4. Symmetric Labels . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Unassigned Upstream Label . . . . . . . . . . . . . . . . . . 5 67 5.1. Processing Rules . . . . . . . . . . . . . . . . . . . . 6 68 5.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 6 69 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6.1. Initial Setup . . . . . . . . . . . . . . . . . . . . . . 7 71 6.2. Wavelength Change . . . . . . . . . . . . . . . . . . . . 8 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 11.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 The Generalized Multi-Protocol Label Switching (GMPLS) Resource 84 reSerVation Protocol with Traffic Engineering (RSVP-TE) extensions 85 for setting up a bidirectional LSP are specified in RFC 3473 86 [RFC3473]. The bidirectional LSP setup is indicated by the presence 87 of an UPSTREAM_LABEL Object in the PATH message. As per the existing 88 setup procedure outlined for a bidirectional LSP, each upstream node 89 must allocate a valid upstream label on the outgoing interface before 90 sending the initial PATH message downstream. However, there are 91 certain scenarios where it is not desirable or possible for a given 92 node to pick the upstream label on its own. This document defines 93 the protocol mechanism to be used in such scenarios. This mechanism 94 enables a given node to offload the task of assigning the upstream 95 label for a given bidirectional LSP onto the network. 97 1.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 2. Use-Case: Wavelength Setup for IP over Optical Networks 105 Consider the network topology depicted in Figure 1. Nodes A and B 106 are client IP routers that are connected to an optical WDM transport 107 network. F, H and I represent WDM nodes. The transponder sits on 108 the router and is directly connected to the add-drop port on a WDM 109 node. 111 The optical signal originating on "Router A" is tuned to a particular 112 wavelength. On "WDM-Node F", it gets multiplexed with optical 113 signals at other wavelengths. Depending on the implementation of 114 this multiplexing function, it may not be acceptable to have the 115 router send signal into the optical network unless it is at the 116 appropriate wavelength. In other words, having the router send 117 signal with a wrong wavelength may adversely impact existing optical 118 trails. If the clients do not have full visibility into the optical 119 network, they are not in a position to pick the correct wavelength 120 up-front. 122 | 123 | +---+ /-\ 124 | | | Router ( ) WDM 125 | +---+ Node \-/ node 126 |________________________________ 128 +---+ /-\ /-\ /-\ +---+ 129 | A |---------( F )---------( H )---------( I )---------| B | 130 +---+ \-/ \-/ \-/ +---+ 132 Sample Topology 134 Figure 1 136 3. The "Crankback Signaling" Approach 138 There are currently no GMPLS RSVP-TE protocol mechanisms that an 139 upstream node can use for indicating that it does not know what 140 upstream label to use and that it needs the downstream node to pick 141 the label on its behalf. 143 The "Crankback Signaling" RFC 4920 [RFC4920] approach can be applied 144 to address the above use-case as shown in the following setup 145 sequence: 147 +---+ /-\ /-\ +---+ 148 | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | 149 +---+ \-/ \-/ +---+ 151 PATH 152 Upstream Label (any available value) 153 ---------------------> 154 PATH-ERR 155 Routing problem/Unacceptable Label Value 156 Acceptable Label Set (L1, L2 .. Ln) 157 <--------------------- 158 PATH 159 Upstream Label (L2) 160 ---------------------> 161 -- ~~ -- ~~ --> 162 PATH 163 --------------------> 164 RESV 165 <-------------------- 166 <-- ~~ -- ~~ -- 167 RESV 168 Label (Assigned) 169 <--------------------- 171 Setup Sequence - Crank-back Approach 173 Figure 2 175 The above approach does work, but there are a few obvious concerns: 177 o Since "Router-A" does not know which upstream label to use, it 178 picks some random label and signals it without programming its 179 data-plane (this is a deviation from the UPSTREAM_LABEL processing 180 procedures outlined in RFC 3473 [RFC3473]). As a result, the 181 outgoing PATH message has no indication of whether the upstream 182 label has been installed along the data-path or not. 184 o Even if "Router-A" somehow correctly guesses an acceptable 185 upstream label upfront, the network may end up finding a path 186 which is suboptimal (there could be a different acceptable 187 upstream label which corresponds to a better path in the network) 189 o The "PATH-ERR with Acceptable Label Set" retry approach is usually 190 used for exception handling. The above solution uses it for 191 almost every single setup request (except in the rare scenario 192 where the appropriate upstream label is guessed correctly). 194 o There is an awkward window between the time the network sends out 195 the PATH-ERR message (with the ACCEPTABLE_LABEL_SET) and receives 196 the corresponding PATH message (with the selected UPSTREAM_LABEL); 197 this window opens up the possibility of the selected 198 UPSTREAM_LABEL to be stale by the time the network receives the 199 retry PATH. 201 o The above solution assumes the use of "symmetric labels" by 202 default. 204 The rest of the sections in this draft present a solution proposal 205 that is devoid of any of the above concerns. 207 4. Symmetric Labels 209 As per RFC 3471 [RFC3471], the upstream label and the downstream 210 label for an LSP at a given hop need not be the same. The use-case 211 discussed in this document pertains to Lambda Switch Capable (LSC) 212 LSPs and it is an undocumented fact that in practice, LSC LSPs always 213 have symmetric labels at each hop along the path of the LSP. 215 The use of the protocol mechanism discussed in this document mandates 216 "Label Symmetry". This mechanism is meant to be used only for 217 bidirectional LSPs that assign symmetric labels at each hop along the 218 path of the LSP. 220 5. Unassigned Upstream Label 222 This document proposes the use of a special label value - 223 "0xFFFFFFFF" (for a 4-byte label) - to indicate an Unassigned 224 Upstream Label. Similar "all-ones" patterns are expected to be used 225 for labels of other sizes. The presence of this value in the 226 UPSTREAM_LABEL object of a PATH message indicates that the upstream 227 node has not assigned an upstream label on its own and has requested 228 the downstream node to provide a label that it can use in both 229 forward and reverse directions. The presence of this value in the 230 UPSTREAM_LABEL object of a PATH message MUST also be interpreted by 231 the receiving node as a request to mandate "symmetric labels" for the 232 LSP. 234 5.1. Processing Rules 236 The Unassigned Upstream Label is used by an upstream node when it is 237 not in a position to pick the upstream label on its own. In such a 238 scenario, the upstream node sends a PATH message downstream with an 239 Unassigned Upstream Label and requests the downstream node to provide 240 a symmetric label. If the upstream node desires to make the 241 downstream node aware of its limitations with respect to label 242 selection, it MUST specify a list of valid labels via the LABEL_SET 243 object as specified in RFC 3473 [RFC3473]. 245 In response, the downstream node picks an appropriate symmetric label 246 and sends it via the LABEL object in the RESV message. The upstream 247 node would then start using this symmetric label for both directions 248 of the LSP. If the downstream node cannot pick the symmetric label, 249 it MUST issue a PATH-ERR message with a "Routing Problem/Unacceptable 250 Label Value" indication. 252 The upstream node will continue to signal the Unassigned Upstream 253 Label in the PATH message even after it receives an appropriate 254 symmetric label in the RESV message. This is done to make sure that 255 the downstream node would pick a different symmetric label if and 256 when it needs to change the label at a later point in time. 258 +----------+ +------------+ 259 ---| Upstream |--------------------| Downstream |--- 260 +----------+ +------------+ 262 PATH 263 Upstream Label (Unassigned) 264 Label-Set (L1, L2 ... Ln) 265 -------------------> 267 RESV 268 Label (Assigned - L2) 269 <------------------- 271 Unassigned UPSTREAM_LABEL 273 Figure 3 275 5.2. Backwards Compatibility 277 If the downstream node is running an older implementation and doesn't 278 understand the semantics of an Unassigned UPSTREAM LABEL, it will 279 either (a) reject the special label value and generate an error as 280 specified in Section 3.1 of RFC 3473 [RFC3473] or (b) accept it and 281 treat it as a valid label. 283 If the behavior that is exhibited is (a), then there are obviously no 284 backwards compatibility concerns. If there is some existing 285 implementation that exhibits the behavior in (b), then there could be 286 some potential issues. However, at the time of publication, there is 287 no documented evidence of any existing implementation that uses the 288 "all-ones" bit pattern as a valid label. Thus, it is safe to assume 289 that the behavior in (b) will never be exhibited. 291 6. Applicability 293 The use-case discussed in Section 2 is revisited to examine how the 294 mechanism proposed in this document allows the optical network to 295 select and communicate the correct wavelength to its clients. 297 6.1. Initial Setup 299 +---+ /-\ /-\ +---+ 300 | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | 301 +---+ \-/ \-/ +---+ 303 PATH 304 Upstream Label (Unassigned/0xFFFFFFFF) 305 ---------------------> 306 -- ~~ -- ~~ --> 307 PATH 308 --------------------> 309 RESV 310 <-------------------- 311 <-- ~~ -- ~~ -- 312 RESV 313 Label (Assigned) 314 <--------------------- 316 Initial Setup Sequence 318 Figure 4 320 Steps: 322 o "Router A" does not have enough information to pick an appropriate 323 client wavelength. It sends a PATH message downstream requesting 324 the network to assign an appropriate symmetric label for its use. 326 Since the client wavelength is unknown, the laser is off at the 327 ingress client. 329 o The downstream node (Node F) receives the PATH message, chooses 330 the appropriate wavelength values and forwards them in appropriate 331 label fields to the egress client ("Router B") 333 o "Router B" receives the PATH message, turns the laser ON and tunes 334 it to the appropriate wavelength (received in the UPSTREAM_LABEL/ 335 LABEL_SET of the PATH) and sends out a RESV message upstream. 337 o The RESV message received by the ingress client carries a valid 338 symmetric label in the LABEL object. "Router A" turns on the 339 laser and tunes it to the wavelength specified in the network 340 assigned symmetric LABEL. 342 For cases where the egress-node relies on RSVP signaling to determine 343 exactly when to start using the LSP, this draft recommends 344 integrating the above sequence with any of the existing graceful 345 setup procedures: 347 o "RESV-CONF" setup procedure (or) 349 o 2-step "ADMIN STATUS" based setup procedure ("A" bit set in the 350 first step; "A" bit cleared when the LSP is ready for use). 352 6.2. Wavelength Change 354 After the LSP is set up, the network MAY decide to change the 355 wavelength for the given LSP. This could be for a variety of reasons 356 - policy reasons, restoration within the core, preemption etc. 358 In such a scenario, if the ingress client receives a changed label 359 via the LABEL object in a RESV modify, it MUST retune the laser at 360 the ingress to the new wavelength. Similarly, if the egress client 361 receives a changed label via UPSTREAM_LABEL/LABEL_SET in a PATH 362 modify, it MUST retune the laser at the egress to the new wavelength. 363 If the node receiving the changed label in a PATH/RESV message does 364 not find the label acceptable, then the corresponding error 365 procedures defined in RFC 3473 [RFC3473] MUST be followed. 367 7. Acknowledgements 369 The authors would like to thank Adrian Farrel and Chris Bowers for 370 their inputs. 372 8. Contributors 374 John Drake 375 Juniper Networks 376 Email: jdrake@juniper.net 378 Gert Grammel 379 Juniper Networks 380 Email: ggrammel@juniper.net 382 Pawel Brzozowski 383 ADVA Optical Networking 384 Email: pbrzozowski@advaoptical.com 386 Zafar Ali 387 Cisco Systems, Inc. 388 Email: zali@cisco.com 390 9. IANA Considerations 392 This document makes no requests for IANA action. 394 10. Security Considerations 396 This document defines a special label value to be carried in the 397 UPSTREAM_LABEL object of a PATH message. This special label value is 398 used to enable the function of requesting network assignment of an 399 upstream label. The changes proposed in this document pertain to the 400 semantics of a specific field in an existing RSVP object and the 401 corresponding procedures. Thus, there are no new security 402 implications raised by this document and the security considerations 403 put together by RFC 3473 [RFC3473] still applies. 405 For a general discussion on MPLS and GMPLS related security issues, 406 see the MPLS/GMPLS security framework RFC 5920 [RFC5920]. 408 11. References 410 11.1. Normative References 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, 414 DOI 10.17487/RFC2119, March 1997, 415 . 417 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 418 Switching (GMPLS) Signaling Functional Description", 419 RFC 3471, DOI 10.17487/RFC3471, January 2003, 420 . 422 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 423 Switching (GMPLS) Signaling Resource ReserVation Protocol- 424 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 425 DOI 10.17487/RFC3473, January 2003, 426 . 428 [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., 429 and G. Ash, "Crankback Signaling Extensions for MPLS and 430 GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007, 431 . 433 11.2. Informative References 435 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 436 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 437 . 439 Authors' Addresses 441 Xian Zhang (editor) 442 Huawei Technologies 444 Email: zhang.xian@huawei.com 446 Vishnu Pavan Beeram (editor) 447 Juniper Networks 449 Email: vbeeram@juniper.net 451 Igor Bryskin 452 Huawei Technologies 454 Email: igor.bryskin@huawei.com 456 Daniele Ceccarelli 457 Ericsson 459 Email: daniele.ceccarelli@ericsson.com 460 Oscar Gonzalez de Dios 461 Telefonica 463 Email: ogondio@tid.es