idnits 2.17.1 draft-ietf-teas-network-assigned-upstream-label-00.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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 (December 09, 2014) is 3423 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 (~~), 2 warnings (==), 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 Igor Bryskin (Ed) 5 ADVA Optical Networking 7 Expires: June 09, 2015 December 09, 2014 9 Network Assigned Upstream-Label 10 draft-ietf-teas-network-assigned-upstream-label-00 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 June 09, 2015. 35 Copyright Notice 37 Copyright (c) 2014 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 GMPLS RSVP-TE protocol mechanism that 53 enables the network to assign an upstream-label for a given LSP. 54 This is useful in scenarios where a given node does not have 55 sufficient information to assign the correct upstream-label on its 56 own and needs to rely on the network to pick an appropriate label. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC-2119 [RFC2119]. 64 Table of Contents 66 1. Introduction...................................................2 67 2. Use-Case: Alien Wavelength Setup...............................3 68 3. The "crank-back" approach......................................3 69 4. Symmetric Labels...............................................5 70 5. Unassigned Upstream Label......................................5 71 5.1. Processing Rules..........................................5 72 5.2. Backwards Compatibility...................................6 73 6. Applicability..................................................6 74 6.1. Initial Setup.............................................7 75 6.2. Wavelength Change.........................................8 76 7. Security Considerations........................................8 77 8. IANA Considerations............................................8 78 9. Normative References...........................................8 79 10. Acknowledgments...............................................8 81 1. Introduction 83 The GMPLS RSVP-TE extensions for setting up a Bidirectional LSP are 84 discussed in [RFC3473]. The Bidirectional LSP setup is indicated by 85 the presence of an UPSTREAM_LABEL Object in the PATH message. As per 86 the existing setup procedure outlined for a Bidirectional LSP, each 87 upstream-node must allocate a valid upstream-label on the outgoing 88 interface before sending the initial PATH message downstream. 89 However, there are certain scenarios where it is not desirable or 90 possible for a given node to pick the upstream-label on its own. 91 This document defines the protocol mechanism to be used in such 92 scenarios. This mechanism enables a given node to offload the task 93 of assigning the upstream-label for a given LSP onto the network. 95 2. Use-Case: Alien Wavelength Setup 97 Consider the network topology depicted in Figure 1. Nodes A and B 98 are client IP routers that are connected to an optical WDM transport 99 network. F, H and I represent WDM nodes. The transponder sits on the 100 router and is directly connected to the add-drop port on a WDM node. 102 The optical signal originating on "Router A" is tuned to a 103 particular wavelength. On "WDM-Node F", it gets multiplexed with 104 optical signals at other wavelengths. Depending on the 105 implementation of this multiplexing function, it may not be 106 acceptable to have the router send signal into the optical network 107 unless it is at the appropriate wavelength. In other words, having 108 the router send signal with a wrong wavelength may adversely impact 109 existing optical trails. If the clients do not have full visibility 110 into the optical network, they are not in a position to pick the 111 correct wavelength up-front. 113 | 114 | +---+ /-\ 115 | | | Router ( ) WDM 116 | +---+ Node \-/ node 117 |________________________________ 119 +---+ /-\ /-\ /-\ +---+ 120 | A |---------( F )---------( H )---------( I )---------| B | 121 +---+ \-/ \-/ \-/ +---+ 123 Figure 1: Sample topology 125 3. The "crank-back" approach 127 There are currently no GMPLS RSVP-TE protocol mechanisms that an 128 upstream-node can use for indicating that it does not know what 129 upstream-label to use and that it needs the downstream-node to pick 130 the label on its behalf. 132 The following setup sequence is an attempt to address the above use- 133 case using existing protocol mechanisms: 135 +---+ /-\ /-\ +---+ 136 | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | 137 +---+ \-/ \-/ +---+ 139 PATH 140 Upstream Label (any available value) 141 ---------------------> 142 PATH-ERROR 143 Routing problem/Unacceptable Label Value 144 Acceptable Label Set (L1, L2 .. Ln) 145 <--------------------- 146 PATH 147 Upstream Label (L2) 148 ---------------------> 149 -- ~~ -- ~~ --> 150 PATH 151 --------------------> 152 RESV 153 <-------------------- 154 <-- ~~ -- ~~ -- 155 RESV 156 Label (Assigned) 157 <--------------------- 159 Figure 2: Setup Sequence - Crank-back Approach 161 The above approach does sort of work, but there are a few obvious 162 concerns: 164 - Since "Router-A" does not know which upstream-label to use, it 165 picks some random label and signals it without programming its 166 data-plane. As a result, the outgoing PATH message has no 167 indication of whether the upstream-label has been installed along 168 the data-path or not. 169 - If "Router-A" somehow correctly guesses (by sheer luck) an 170 acceptable upstream label upfront, the network may end up finding 171 a path which is suboptimal (there could be a different acceptable 172 upstream label which corresponds to a better path in the network) 173 - The "Path-Error with Acceptable Label Set" retry approach is 174 usually used for exception handling. The above solution uses it 175 for almost every single setup request (except in the rare scenario 176 where the appropriate upstream-label is guessed correctly). 177 - There is an awkward window between the time the network sends out 178 the Path-Error (with the ACCEPTABLE_LABEL_SET) and receives the 179 corresponding Path (with the selected UPSTREAM_LABEL); this window 180 opens up the possibility of the selected UPSTREAM_LABEL to be 181 stale by the time the network receives the retry PATH. 182 - The above solution assumes the use of "symmetric labels" by 183 default. 185 The rest of the sections in this draft discuss a solution proposal 186 that is devoid of any of the above concerns. 188 4. Symmetric Labels 190 As per [RFC3471], the upstream-label and the downstream-label for an 191 LSP at a given hop need not be the same. The use-case discussed in 192 this document pertains to Lambda Switch Capable (LSC) LSPs and it is 193 an undocumented fact that in practice, LSC LSPs always have 194 symmetric labels at each hop along the path of the LSP. 196 The use of the protocol mechanism discussed in this document 197 mandates "Label Symmetry". This mechanism is meant to be used only 198 for Bidirectional LSPs that assign Symmetric Labels at each hop 199 along the path of the LSP. 201 5. Unassigned Upstream Label 203 This document proposes the use of a special label value - 204 "0xFFFFFFFF" - to indicate an Unassigned Label. The presence of this 205 value in the UPSTREAM_LABEL object of a PATH message indicates that 206 the upstream-node has not assigned an upstream label on its own and 207 has requested the downstream-node to provide a label that it can use 208 in both forward and reverse directions. The presence of this value 209 in the UPSTREAM LABEL object of a PATH message can also be 210 interpreted as a request to mandate "symmetric labels" for the LSP 211 at the given hop. 213 5.1. Processing Rules 215 The Unassigned Upstream Label is used by an upstream-node when it is 216 not in a position to pick the upstream label on its own. In such a 217 scenario, the upstream-node sends a PATH message downstream with an 218 Unassigned Upstream Label and requests the downstream-node to 219 provide a symmetric label. If the upstream-node desires to make the 220 downstream-node aware of its limitations with respect to label 221 selection, it has the option to specify a list of valid labels via 222 the LABEL_SET object. 224 In response, the downstream-node picks an appropriate symmetric 225 label and sends it via the LABEL object in the RESV message. The 226 upstream-node would then start using this symmetric label for both 227 directions of the LSP. If the downstream-node cannot pick the 228 symmetric label, it MUST issue a PATH-ERR message with a "Routing 229 Problem/Unacceptable Label Value" indication. 231 The upstream-node will continue to signal the Unassigned Upstream 232 Label in the PATH message even after it receives an appropriate 233 symmetric label in the RESV message. This is done to make sure that 234 the downstream-node would pick a symmetric label if and when it 235 needs to change the RESV label at a later point in time. 237 +----------+ +------------+ 238 ---| Upstream |--------------------| Downstream |--- 239 +----------+ +------------+ 241 PATH 242 Upstream Label (Unassigned) 243 Label-Set (L1, L2 ... Ln) 244 -------------------> 246 RESV 247 Label (Assigned - L2) 248 <------------------- 250 Figure 3: Unassigned UPSTREAM_LABEL 252 5.2. Backwards Compatibility 254 If the downstream-node is running an older implementation (which may 255 be using the "crank-back" approach discussed in Section 3) and 256 doesn't understand the semantics of an Unassigned UPSTREAM LABEL, it 257 will either (a) reject the special label value and generate an error 258 or (b) accept it and treat it as a valid label. 260 If the behavior that is exhibited is (a), then there are obviously 261 no backwards compatibility concerns. Ingress implementations may 262 even choose to adopt the "crank-back" approach in such cases. If 263 there is some existing implementation that exhibits the behavior in 264 (b), then there could be some potential issues. The use-case 265 discussed in this draft pertains to LSC LSPs and it is safe to 266 assume that the behavior in (b) will not be exhibited for such LSPs. 268 6. Applicability 270 Let us revisit the "alien wavelength" use-case discussed in Section 271 2 and examine how the mechanism proposed in this document allows the 272 optical network to select and communicate the correct wavelength to 273 its clients. 275 6.1. Initial Setup 277 +---+ /-\ /-\ +---+ 278 | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | 279 +---+ \-/ \-/ +---+ 281 PATH 282 Upstream Label (Unassigned) 283 ---------------------> 284 -- ~~ -- ~~ --> 285 PATH 286 --------------------> 287 RESV 288 <-------------------- 289 <-- ~~ -- ~~ -- 290 RESV 291 Label (Assigned) 292 <--------------------- 294 Figure 4: Alien Wavelength - Initial Setup 296 Steps: 297 - "Router A" does not have enough information to pick an 298 appropriate client wavelength. It sends a PATH downstream 299 requesting the network to assign an appropriate symmetric label 300 for it to use. Since the client wavelength is unknown, the 301 laser is off at the ingress client. 302 - The network receives the PATH, chooses the appropriate 303 wavelength values and forwards them in appropriate label fields 304 to the egress client ("Router B") 305 - "Router B" receives the PATH, turns the laser ON and tunes it 306 to the appropriate wavelength (received in the 307 UPSTREAM_LABEL/LABEL_SET of the PATH) and sends out a RESV 308 upstream. 309 - The RESV received by the ingress client carries a valid 310 symmetric label in the LABEL object. "Router A" turns on the 311 laser and tunes it to the wavelength specified in the network 312 assigned symmetric LABEL. 314 For cases where the egress-node relies on RSVP signaling to 315 determine exactly when to start using the LSP, this draft recommends 316 integrating the above sequence with any of the existing graceful 317 setup procedures: 318 - "RESV-CONF" setup procedure (or) 319 - 2-step "ADMIN STATUS" based setup procedure ("A" bit set in the 320 first step; "A" bit cleared when the LSP is ready for use). 322 6.2. Wavelength Change 324 After the LSP is set up, the network MAY decide to change the 325 wavelength for the given LSP. This could be for a variety of reasons 326 - policy reasons, restoration within the core, preemption etc. 328 In such a scenario, if the ingress client receives a changed label 329 via the LABEL object in a RESV modify, it MUST retune the laser at 330 the ingress to the new wavelength. Similarly if the egress client 331 receives a changed label via UPSTREAM_LABEL/LABEL_SET in a PATH 332 modify, it MUST retune the laser at the egress to the new 333 wavelength. 335 7. Security Considerations 337 TBD 339 8. IANA Considerations 341 TBD 343 9. Normative References 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 349 Signaling Functional Description", RFC 3471, January 350 2003 352 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 353 Signaling Resource Reservation Protocol-Traffic 354 Engineering Extensions", RFC 3473, January 2003. 356 10. Acknowledgments 358 TBD 360 Authors' Addresses 362 Vishnu Pavan Beeram 363 Juniper Networks 364 Email: vbeeram@juniper.net 366 John Drake 367 Juniper Networks 368 Email: jdrake@juniper.net 370 Gert Grammel 371 Juniper Networks 372 Email: ggrammel@juniper.net 374 Igor Bryskin 375 ADVA Optical Networking 376 Email: ibryskin@advaoptical.com 378 Pawel Brzozowski 379 ADVA Optical Networking 380 Email: pbrzozowski@advaoptical.com 382 Daniele Ceccarelli 383 Ericsson 384 Email: daniele.ceccarelli@ericsson.com 386 Oscar Gonzalez de Dios 387 Telefonica 388 Email: ogondio@tid.es