idnits 2.17.1 draft-ietf-teas-network-assigned-upstream-label-03.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 (July 07, 2016) is 2849 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 Xian Zhang (Ed) 3 Internet Draft Huawei Technologies 4 Intended status: Standards Track Vishnu Pavan Beeram (Ed) 5 Juniper Networks 7 Expires: January 07, 2017 July 07, 2016 9 Network Assigned Upstream-Label 10 draft-ietf-teas-network-assigned-upstream-label-03 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on January 07, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 This document discusses a Generalized Multi-Protocol Label Switching 53 (GMPLS) Resource reSerVation Protocol with Traffic Engineering 54 (RSVP-TE) mechanism that enables the network to assign an upstream 55 label for a bidirectional LSP. This is useful in scenarios where a 56 given node does not have sufficient information to assign the 57 correct upstream label on its own and needs to rely on the 58 downstream node to pick an appropriate label. 60 Conventions used in this document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC-2119 [RFC2119]. 66 Table of Contents 68 1. Introduction...................................................2 69 2. Use-Case: Wavelength Setup for IP over Optical Networks........3 70 3. The "Crankback Signaling" Approach.............................4 71 4. Symmetric Labels...............................................5 72 5. Unassigned Upstream Label......................................5 73 5.1. Processing Rules..........................................6 74 5.2. Backwards Compatibility...................................6 75 6. Applicability..................................................7 76 6.1. Initial Setup.............................................7 77 6.2. Wavelength Change.........................................8 78 7. Security Considerations........................................8 79 8. IANA Considerations............................................9 80 9. References.....................................................9 81 9.1. Normative References......................................9 82 9.2. Informative References....................................9 83 10. Acknowledgments...............................................9 84 Authors' Addresses................................................9 85 Contributors.....................................................10 87 1. Introduction 89 The Generalized Multi-Protocol Label Switching (GMPLS) Resource 90 reSerVation Protocol with Traffic Engineering (RSVP-TE) extensions 91 for setting up a bidirectional LSP are specified in [RFC3473]. The 92 bidirectional LSP setup is indicated by the presence of an 93 UPSTREAM_LABEL Object in the PATH message. As per the existing 94 setup procedure outlined for a bidirectional LSP, each upstream node 95 must allocate a valid upstream label on the outgoing interface 96 before sending the initial PATH message downstream. However, there 97 are certain scenarios where it is not desirable or possible for a 98 given node to pick the upstream label on its own. This document 99 defines the protocol mechanism to be used in such scenarios. This 100 mechanism enables a given node to offload the task of assigning the 101 upstream label for a given bidirectional LSP onto the network. 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 112 particular wavelength. On "WDM-Node F", it gets multiplexed with 113 optical signals at other wavelengths. Depending on the 114 implementation of this multiplexing function, it may not be 115 acceptable to have the router send signal into the optical network 116 unless it is at the appropriate wavelength. In other words, having 117 the router send signal with a wrong wavelength may adversely impact 118 existing optical trails. If the clients do not have full visibility 119 into the optical network, they are not in a position to pick the 120 correct wavelength up-front. 122 | 123 | +---+ /-\ 124 | | | Router ( ) WDM 125 | +---+ Node \-/ node 126 |________________________________ 128 +---+ /-\ /-\ /-\ +---+ 129 | A |---------( F )---------( H )---------( I )---------| B | 130 +---+ \-/ \-/ \-/ +---+ 132 Figure 1: Sample Topology 134 3. The "Crankback Signaling" Approach 136 There are currently no GMPLS RSVP-TE protocol mechanisms that an 137 upstream node can use for indicating that it does not know what 138 upstream label to use and that it needs the downstream node to pick 139 the label on its behalf. 141 The "Crankback Signaling" [RFC4920] approach can be applied to 142 address the above use-case as shown in the following setup sequence: 144 +---+ /-\ /-\ +---+ 145 | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | 146 +---+ \-/ \-/ +---+ 148 PATH 149 Upstream Label (any available value) 150 ---------------------> 151 PATH-ERR 152 Routing problem/Unacceptable Label Value 153 Acceptable Label Set (L1, L2 .. Ln) 154 <--------------------- 155 PATH 156 Upstream Label (L2) 157 ---------------------> 158 -- ~~ -- ~~ --> 159 PATH 160 --------------------> 161 RESV 162 <-------------------- 163 <-- ~~ -- ~~ -- 164 RESV 165 Label (Assigned) 166 <--------------------- 168 Figure 2: Setup Sequence - Crank-back Approach 170 The above approach does work, but there are a few obvious concerns: 172 - Since "Router-A" does not know which upstream label to use, it 173 picks some random label and signals it without programming its 174 data-plane (this is a deviation from the UPSTREAM_LABEL processing 175 procedures outlined in [RFC3473]). As a result, the outgoing PATH 176 message has no indication of whether the upstream label has been 177 installed along the data-path or not. 178 - Even if "Router-A" somehow correctly guesses an acceptable 179 upstream label upfront, the network may end up finding a path 180 which is suboptimal (there could be a different acceptable 181 upstream label which corresponds to a better path in the network) 182 - The "PATH-ERR with Acceptable Label Set" retry approach is usually 183 used for exception handling. The above solution uses it for 184 almost every single setup request (except in the rare scenario 185 where the appropriate upstream label is guessed correctly). 186 - There is an awkward window between the time the network sends out 187 the PATH-ERR message (with the ACCEPTABLE_LABEL_SET) and receives 188 the corresponding PATH message (with the selected UPSTREAM_LABEL); 189 this window opens up the possibility of the selected 190 UPSTREAM_LABEL to be stale by the time the network receives the 191 retry PATH. 192 - The above solution assumes the use of "symmetric labels" by 193 default. 195 The rest of the sections in this draft present a solution proposal 196 that is devoid of any of the above concerns. 198 4. Symmetric Labels 200 As per [RFC3471], the upstream label and the downstream label for an 201 LSP at a given hop need not be the same. The use-case discussed in 202 this document pertains to Lambda Switch Capable (LSC) LSPs and it is 203 an undocumented fact that in practice, LSC LSPs always have 204 symmetric labels at each hop along the path of the LSP. 206 The use of the protocol mechanism discussed in this document 207 mandates "Label Symmetry". This mechanism is meant to be used only 208 for bidirectional LSPs that assign symmetric labels at each hop 209 along the path of the LSP. 211 5. Unassigned Upstream Label 213 This document proposes the use of a special label value - 214 "0xFFFFFFFF" (for a 4-byte label) - to indicate an Unassigned 215 Upstream Label. Similar "all-ones" patterns are expected to be used 216 for labels of other sizes. The presence of this value in the 217 UPSTREAM_LABEL object of a PATH message indicates that the upstream 218 node has not assigned an upstream label on its own and has requested 219 the downstream node to provide a label that it can use in both 220 forward and reverse directions. The presence of this value in the 221 UPSTREAM_LABEL object of a PATH message MUST also be interpreted by 222 the receiving node as a request to mandate "symmetric labels" for 223 the LSP. 225 5.1. Processing Rules 227 The Unassigned Upstream Label is used by an upstream node when it is 228 not in a position to pick the upstream label on its own. In such a 229 scenario, the upstream node sends a PATH message downstream with an 230 Unassigned Upstream Label and requests the downstream node to 231 provide a symmetric label. If the upstream node desires to make the 232 downstream node aware of its limitations with respect to label 233 selection, it MUST specify a list of valid labels via the LABEL_SET 234 object as specified in [RFC3473]. 236 In response, the downstream node picks an appropriate symmetric 237 label and sends it via the LABEL object in the RESV message. The 238 upstream node would then start using this symmetric label for both 239 directions of the LSP. If the downstream node cannot pick the 240 symmetric label, it MUST issue a PATH-ERR message with a "Routing 241 Problem/Unacceptable Label Value" indication. 243 The upstream node will continue to signal the Unassigned Upstream 244 Label in the PATH message even after it receives an appropriate 245 symmetric label in the RESV message. This is done to make sure that 246 the downstream node would pick a different symmetric label if and 247 when it needs to change the label at a later point in time. 249 +----------+ +------------+ 250 ---| Upstream |--------------------| Downstream |--- 251 +----------+ +------------+ 253 PATH 254 Upstream Label (Unassigned) 255 Label-Set (L1, L2 ... Ln) 256 -------------------> 258 RESV 259 Label (Assigned - L2) 260 <------------------- 262 Figure 3: Unassigned UPSTREAM_LABEL 264 5.2. Backwards Compatibility 266 If the downstream node is running an older implementation and 267 doesn't understand the semantics of an Unassigned UPSTREAM LABEL, it 268 will either (a) reject the special label value and generate an error 269 as specified in Section 3.1 of [RFC3473] or (b) accept it and treat 270 it as a valid label. 271 If the behavior that is exhibited is (a), then there are obviously 272 no backwards compatibility concerns. If there is some existing 273 implementation that exhibits the behavior in (b), then there could 274 be some potential issues. However, at the time of publication, 275 there is no documented evidence of any existing implementation that 276 uses the "all-ones" bit pattern as a valid label. Thus, it is safe 277 to assume that the behavior in (b) will never be exhibited. 279 6. Applicability 281 The use-case discussed in Section 2 is revisited to examine how the 282 mechanism proposed in this document allows the optical network to 283 select and communicate the correct wavelength to its clients. 285 6.1. Initial Setup 287 +---+ /-\ /-\ +---+ 288 | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | 289 +---+ \-/ \-/ +---+ 291 PATH 292 Upstream Label (Unassigned/0xFFFFFFFF) 293 ---------------------> 294 -- ~~ -- ~~ --> 295 PATH 296 --------------------> 297 RESV 298 <-------------------- 299 <-- ~~ -- ~~ -- 300 RESV 301 Label (Assigned) 302 <--------------------- 304 Figure 4: Initial Setup Sequence 306 Steps: 307 - "Router A" does not have enough information to pick an 308 appropriate client wavelength. It sends a PATH message 309 downstream requesting the network to assign an appropriate 310 symmetric label for its use. Since the client wavelength is 311 unknown, the laser is off at the ingress client. 312 - The downstream node (Node F) receives the PATH message, chooses 313 the appropriate wavelength values and forwards them in 314 appropriate label fields to the egress client ("Router B") 315 - "Router B" receives the PATH message, turns the laser ON and 316 tunes it to the appropriate wavelength (received in the 317 UPSTREAM_LABEL/LABEL_SET of the PATH) and sends out a RESV 318 message upstream. 319 - The RESV message received by the ingress client carries a valid 320 symmetric label in the LABEL object. "Router A" turns on the 321 laser and tunes it to the wavelength specified in the network 322 assigned symmetric LABEL. 324 For cases where the egress-node relies on RSVP signaling to 325 determine exactly when to start using the LSP, this draft recommends 326 integrating the above sequence with any of the existing graceful 327 setup procedures: 328 - "RESV-CONF" setup procedure (or) 329 - 2-step "ADMIN STATUS" based setup procedure ("A" bit set in the 330 first step; "A" bit cleared when the LSP is ready for use). 332 6.2. Wavelength Change 334 After the LSP is set up, the network MAY decide to change the 335 wavelength for the given LSP. This could be for a variety of 336 reasons - policy reasons, restoration within the core, preemption 337 etc. 339 In such a scenario, if the ingress client receives a changed label 340 via the LABEL object in a RESV modify, it MUST retune the laser at 341 the ingress to the new wavelength. Similarly, if the egress client 342 receives a changed label via UPSTREAM_LABEL/LABEL_SET in a PATH 343 modify, it MUST retune the laser at the egress to the new 344 wavelength. If the node receiving the changed label in a PATH/RESV 345 message does not find the label acceptable, then the corresponding 346 error procedures defined in [RFC3473] MUST be followed. 348 7. Security Considerations 350 This document defines a special label value to be carried in the 351 UPSTREAM_LABEL object of a PATH message. This special label value 352 is used to enable the function of requesting network assignment of 353 an upstream label. The changes proposed in this document pertain to 354 the semantics of a specific field in an existing RSVP object and the 355 corresponding procedures. Thus, there are no new security 356 implications raised by this document and the security considerations 357 put together by [RFC3473] still applies. 359 For a general discussion on MPLS and GMPLS related security issues, 360 see the MPLS/GMPLS security framework [RFC5920]. 361 8. IANA Considerations 363 This document makes no requests for IANA action. 365 9. References 367 9.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 373 Signaling Functional Description", RFC 3471, January 374 2003 376 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 377 Signaling Resource Reservation Protocol-Traffic 378 Engineering Extensions", RFC 3473, January 2003. 380 [RFC4920] Farrel, A., "Crankback Signaling Extensions for MPLS 381 and GMPLS RSVP-TE", RFC 4920, July 2007. 383 9.2. Informative References 385 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 386 Networks", RFC 5920, July 2010. 388 10. Acknowledgments 390 The authors would like to thank Adrian Farrel and Chris Bowers for 391 their inputs. 393 Authors' Addresses 395 Xian Zhang 396 Huawei Technologies 397 Email: zhang.xian@huawei.com 398 Vishnu Pavan Beeram 399 Juniper Networks 400 Email: vbeeram@juniper.net 402 Igor Bryskin 403 Huawei Technologies 404 Email: igor.bryskin@huawei.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 Contributors 416 John Drake 417 Juniper Networks 418 Email: jdrake@juniper.net 420 Gert Grammel 421 Juniper Networks 422 Email: ggrammel@juniper.net 424 Pawel Brzozowski 425 ADVA Optical Networking 426 Email: pbrzozowski@advaoptical.com 428 Zafar Ali 429 Cisco Systems, Inc. 430 Email: zali@cisco.com