idnits 2.17.1 draft-ietf-teas-network-assigned-upstream-label-11.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 (Using the creation date from RFC3471, updated by this document, for RFC5378 checks: 2000-10-23) -- 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 (December 30, 2017) is 2281 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 (==), 2 comments (--). 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 Updates: 3471, 3473, 6205 (if approved) V. Beeram, Ed. 5 Intended status: Standards Track Juniper Networks 6 Expires: July 3, 2018 I. Bryskin 7 Huawei Technologies 8 D. Ceccarelli 9 Ericsson 10 O. Gonzalez de Dios 11 Telefonica 12 December 30, 2017 14 Network Assigned Upstream-Label 15 draft-ietf-teas-network-assigned-upstream-label-11 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 Label Switched Path (LSP). This is useful in 23 scenarios where a given node does not have sufficient information to 24 assign the correct upstream label on its own and needs to rely on the 25 downstream node to pick an appropriate label. This document updates 26 RFCs 3471, 3473 and 6205 as it defines processing for a special label 27 value in the UPSTREAM_LABEL object. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 33 "OPTIONAL" in this document are to be interpreted as described in BCP 34 14 [RFC2119] [RFC8174] when, and only when, they appear in all 35 capitals, as shown here. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on July 3, 2018. 54 Copyright Notice 56 Copyright (c) 2017 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Unassigned Upstream Label . . . . . . . . . . . . . . . . . . 3 73 2.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 5 75 3. Use-Case: Wavelength Setup for IP over Optical Networks . . . 5 76 3.1. Initial Setup . . . . . . . . . . . . . . . . . . . . . . 5 77 3.2. Wavelength Change . . . . . . . . . . . . . . . . . . . . 7 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 80 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 81 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 84 8.2. Informative References . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 87 1. Introduction 89 A functional description of the Generalized Multi-Protocol Label 90 Switching (GMPLS) signaling extensions for setting up a bidirectional 91 Label Switched Path (LSP) is provided in [RFC3471]. The GMPLS 92 Resource reSerVation Protocol with Traffic Engineering (RSVP-TE) 93 extensions for setting up a bidirectional LSP are specified in 94 [RFC3473]. The bidirectional LSP setup is indicated by the presence 95 of an UPSTREAM_LABEL object in the Path message. As per the existing 96 setup procedure outlined for a bidirectional LSP, each upstream node 97 must allocate a valid upstream label on the outgoing interface before 98 sending the initial Path message downstream. However, there are 99 certain scenarios (see Section 3) where it is not desirable or 100 possible for a given node to pick the upstream label on its own. 101 This document defines the protocol mechanism to be used in such 102 scenarios. This mechanism enables a given node to offload the task 103 of assigning the upstream label for a given bidirectional LSP to 104 nodes downstream in the network. It is meant to be used only for 105 bidirectional LSPs that assign symmetric labels at each hop along the 106 path of the LSP. Bidirectional Lambda Switch Capable (LSC) LSPs use 107 symmetric lambda labels (format specified in [RFC6205]) at each hop 108 along the path of the LSP. 110 As per the bidirectional LSP setup procedures specified in [RFC3471] 111 and [RFC3473], the UPSTREAM_LABEL object must indicate a label that 112 is valid for forwarding. This document updates that by allowing the 113 UPSTREAM_LABEL object to indicate a special label that isn't valid 114 for forwarding. As per the bidirectional LSC LSP setup procedures 115 specified in [RFC6205], the LABEL_SET object and the UPSTREAM_LABEL 116 object must contain the same label value. This document updates that 117 by allowing the UPSREAM_LABEL object to carry a special label value 118 that is different from the one used in the LABEL_SET object. 120 2. Unassigned Upstream Label 122 This document defines a special label value - "0xFFFFFFFF" (for a 123 4-octet label) - to indicate an Unassigned Upstream Label. Similar 124 "all-ones" patterns are expected to be used for labels of other 125 sizes. 127 0 1 2 3 128 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 |1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1| 131 | ... | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 Figure 1: Unassigned UPSTREAM_LABEL - "all-ones" Pattern 136 The presence of this value in the UPSTREAM_LABEL object of a Path 137 message indicates that the upstream node has not assigned an upstream 138 label on its own and has requested the downstream node to provide a 139 label that it can use in both the forward and reverse directions. 140 The presence of this value in the UPSTREAM_LABEL object of a Path 141 message MUST also be interpreted by the receiving node as a request 142 to mandate symmetric labels for the LSP. 144 2.1. Procedures 146 The scope of the procedures is limited to the exchange and processing 147 of messages between an upstream node and its immediate downstream 148 node. The Unassigned Upstream Label is used by an upstream node when 149 it is not in a position to pick the upstream label on its own. In 150 such a scenario, the upstream node sends a Path message downstream 151 with an Unassigned Upstream Label and requests the downstream node to 152 provide a symmetric label. If the upstream node desires to make the 153 downstream node aware of its limitations with respect to label 154 selection, it MUST specify a list of valid labels via the LABEL_SET 155 object as specified in [RFC3473]. 157 In response, the downstream node picks an appropriate symmetric label 158 and sends it via the LABEL object in the Resv message. The upstream 159 node would then start using this symmetric label for both directions 160 of the LSP. If the downstream node cannot pick the symmetric label, 161 it MUST issue a PathErr message with a "Routing Problem/Unacceptable 162 Label Value" indication. If the upstream node that signals an 163 Unassigned Upstream Label receives a label with the "all-ones" 164 pattern in the LABEL object of the Resv message, it MUST issue a 165 ResvErr message with a "Routing Problem/Unacceptable Label" 166 indication. 168 The upstream node will continue to signal the Unassigned Upstream 169 Label in the Path message even after it receives an appropriate 170 symmetric label in the Resv message. This is done to make sure that 171 the downstream node would pick a different symmetric label if and 172 when it needs to change the label at a later time. If the upstream 173 node receives an unacceptable changed label, then it MUST issue a 174 ResvErr message with a "Routing Problem/Unacceptable Label" 175 indication. 177 +----------+ +------------+ 178 ---| Upstream |--------------------| Downstream |--- 179 +----------+ +------------+ 181 Path 182 Upstream Label (Unassigned) 183 Label-Set (L1, L2 ... Ln) 184 -------------------> 186 Resv 187 Label (Assigned - L2) 188 <------------------- 190 Figure 2: Signaling Sequence 192 2.2. Backwards Compatibility 194 If the downstream node is running an implementation that doesn't 195 support the semantics of an Unassigned UPSTREAM LABEL, it will either 196 (a) reject the special label value and generate an error as specified 197 in Section 3.1 of [RFC3473] or (b) accept it and treat it as a valid 198 label. 200 If the behavior that is exhibited is (a), then there are no backwards 201 compatibility concerns. If the behavior that is exhibited is (b), 202 then the downstream node will send a label with the "all-ones" 203 pattern in the LABEL object of the Resv message. In response, the 204 upstream node will issue a ResvErr message with a "Routing Problem/ 205 Unassigned Label" indication. 207 3. Use-Case: Wavelength Setup for IP over Optical Networks 209 Consider the network topology depicted in Figure 3. Nodes A and B 210 are client IP routers that are connected to an optical Wavelength 211 Division Multiplexing (WDM) transport network. F and I represent WDM 212 nodes. The transponder sits on the router and is directly connected 213 to the add-drop port on a WDM node. 215 The optical signal originating on "Router A" is tuned to a particular 216 wavelength. On "WDM-Node F", it gets multiplexed with optical 217 signals at other wavelengths. Depending on the implementation of 218 this multiplexing function, it may not be acceptable to have the 219 router send the signal into the optical network unless it is at the 220 appropriate wavelength. In other words, having the router send 221 signals with a wrong wavelength may adversely impact existing optical 222 trails. If the clients do not have full visibility into the optical 223 network, they are not in a position to pick the correct wavelength in 224 advance. 226 The rest of this section examines how the protocol mechanism proposed 227 in this document allows the optical network to select and communicate 228 the correct wavelength to its clients. 230 3.1. Initial Setup 231 +---+ /-\ /-\ +---+ 232 | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | 233 +---+ \-/ \-/ +---+ 235 Path 236 Upstream Label (Unassigned/0xFFFFFFFF) 237 ---------------------> 238 -- ~~ -- ~~ --> 239 Path 240 --------------------> 241 Resv 242 <-------------------- 243 <-- ~~ -- ~~ -- 244 Resv 245 Label (Assigned) 246 <--------------------- 248 Figure 3: Initial Setup Sequence 250 Steps: 252 o "Router A" does not have enough information to pick an appropriate 253 client wavelength. It sends a Path message downstream requesting 254 the network to assign an appropriate symmetric label for its use. 255 Since the client wavelength is unknown, the laser is off at the 256 ingress client. 258 o The downstream node (Node F) receives the Path message, chooses 259 the appropriate wavelength values and forwards them in appropriate 260 label fields to the egress client ("Router B"). 262 o "Router B" receives the Path message, turns the laser ON and tunes 263 it to the appropriate wavelength (received in the UPSTREAM_LABEL/ 264 LABEL_SET of the Path) and sends a Resv message upstream. 266 o The Resv message received by the ingress client carries a valid 267 symmetric label in the LABEL object. "Router A" turns on the 268 laser and tunes it to the wavelength specified in the network 269 assigned symmetric LABEL. 271 For cases where the egress-node relies on RSVP signaling to determine 272 exactly when to start using the LSP, implementations may choose to 273 integrate the above sequence with any of the existing graceful setup 274 procedures: 276 o "ResvConf" setup procedure ([RFC2205]) 277 o 2-step "ADMIN STATUS" based setup procedure ("A" bit set in the 278 first step; "A" bit cleared when the LSP is ready for use). 279 ([RFC3473]) 281 3.2. Wavelength Change 283 After the LSP is set up, the network may decide to change the 284 wavelength for the given LSP. This could be for a variety of reasons 285 including policy reasons, restoration within the core, preemption, 286 etc. 288 In such a scenario, if the ingress client receives a changed label 289 via the LABEL object in a modified Resv message, it retunes the laser 290 at the ingress to the new wavelength. Similarly, if the egress 291 client receives a changed label via UPSTREAM_LABEL/LABEL_SET in a 292 modified Path message, it retunes the laser at the egress to the new 293 wavelength. 295 4. IANA Considerations 297 IANA maintains the "Generalized Multi-Protocol Label Switching 298 (GMPLS) Signaling Parameters" registry. IANA is requested to add a 299 new subregistry for "Special Purpose Generalized Label Values". New 300 values are assigned according to Standards Action. 302 Special Purpose Generalized Label Values 304 Pattern/ Label Name Applicable Reference 305 Value Objects 306 -------- ---------------- -------------- ---------- 307 all-ones Unassigned UPSTREAM_LABEL [This.I-D] 308 Upstream Label 310 5. Security Considerations 312 This document defines a special label value to be carried in the 313 UPSTREAM_LABEL object of a Path message. This special label value is 314 used to enable the function of requesting network assignment of an 315 upstream label. The changes proposed in this document pertain to the 316 semantics of a specific field in an existing RSVP object and the 317 corresponding procedures. Thus, there are no new security 318 implications raised by this document and the security considerations 319 discussed by [RFC3473] still apply. 321 For a general discussion on MPLS and GMPLS related security issues, 322 see the MPLS/GMPLS security framework [RFC5920]. 324 6. Acknowledgements 326 The authors would like to thank Adrian Farrel and Chris Bowers for 327 their inputs. 329 7. Contributors 331 John Drake 332 Juniper Networks 333 Email: jdrake@juniper.net 335 Gert Grammel 336 Juniper Networks 337 Email: ggrammel@juniper.net 339 Pawel Brzozowski 340 ADVA Optical Networking 341 Email: pbrzozowski@advaoptical.com 343 Zafar Ali 344 Cisco Systems, Inc. 345 Email: zali@cisco.com 347 8. References 349 8.1. Normative References 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, 353 DOI 10.17487/RFC2119, March 1997, . 356 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 357 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 358 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 359 September 1997, . 361 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 362 Switching (GMPLS) Signaling Functional Description", 363 RFC 3471, DOI 10.17487/RFC3471, January 2003, 364 . 366 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 367 Switching (GMPLS) Signaling Resource ReserVation Protocol- 368 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 369 DOI 10.17487/RFC3473, January 2003, . 372 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 373 Lambda-Switch-Capable (LSC) Label Switching Routers", 374 RFC 6205, DOI 10.17487/RFC6205, March 2011, 375 . 377 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 378 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 379 May 2017, . 381 8.2. Informative References 383 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 384 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 385 . 387 Authors' Addresses 389 Xian Zhang (editor) 390 Huawei Technologies 392 Email: zhang.xian@huawei.com 394 Vishnu Pavan Beeram (editor) 395 Juniper Networks 397 Email: vbeeram@juniper.net 399 Igor Bryskin 400 Huawei Technologies 402 Email: igor.bryskin@huawei.com 404 Daniele Ceccarelli 405 Ericsson 407 Email: daniele.ceccarelli@ericsson.com 409 Oscar Gonzalez de Dios 410 Telefonica 412 Email: ogondio@tid.es