idnits 2.17.1 draft-ietf-teas-network-assigned-upstream-label-05.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 13, 2017) is 2600 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 14, 2017 Juniper Networks 6 I. Bryskin 7 Huawei Technologies 8 D. Ceccarelli 9 Ericsson 10 O. Gonzalez de Dios 11 Telefonica 12 March 13, 2017 14 Network Assigned Upstream-Label 15 draft-ietf-teas-network-assigned-upstream-label-05 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 14, 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. Unassigned Upstream Label . . . . . . . . . . . . . . . . . . 3 64 2.1. Processing Rules . . . . . . . . . . . . . . . . . . . . 3 65 2.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 4 66 3. Use-Case: Wavelength Setup for IP over Optical Networks . . . 4 67 3.1. Initial Setup . . . . . . . . . . . . . . . . . . . . . . 5 68 3.2. Wavelength Change . . . . . . . . . . . . . . . . . . . . 6 69 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 8.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 The Generalized Multi-Protocol Label Switching (GMPLS) Resource 81 reSerVation Protocol with Traffic Engineering (RSVP-TE) extensions 82 for setting up a bidirectional LSP are specified in [RFC3473]. The 83 bidirectional LSP setup is indicated by the presence of an 84 UPSTREAM_LABEL Object in the PATH message. As per the existing setup 85 procedure outlined for a bidirectional LSP, each upstream node must 86 allocate a valid upstream label on the outgoing interface before 87 sending the initial PATH message downstream. However, there are 88 certain scenarios where it is not desirable or possible for a given 89 node to pick the upstream label on its own. This document defines 90 the protocol mechanism to be used in such scenarios. This mechanism 91 enables a given node to offload the task of assigning the upstream 92 label for a given bidirectional LSP to nodes downstream in the 93 network. It is meant to be used only for bidirectional LSPs that 94 assign symmetric labels at each hop along the path of the LSP. 96 1.1. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. Unassigned Upstream Label 104 This document proposes the use of a special label value - 105 "0xFFFFFFFF" (for a 4-byte label) - to indicate an Unassigned 106 Upstream Label. Similar "all-ones" patterns are expected to be used 107 for labels of other sizes. The presence of this value in the 108 UPSTREAM_LABEL object of a PATH message indicates that the upstream 109 node has not assigned an upstream label on its own and has requested 110 the downstream node to provide a label that it can use in both 111 forward and reverse directions. The presence of this value in the 112 UPSTREAM_LABEL object of a PATH message MUST also be interpreted by 113 the receiving node as a request to mandate symmetric labels for the 114 LSP. 116 2.1. Processing Rules 118 The Unassigned Upstream Label is used by an upstream node when it is 119 not in a position to pick the upstream label on its own. In such a 120 scenario, the upstream node sends a PATH message downstream with an 121 Unassigned Upstream Label and requests the downstream node to provide 122 a symmetric label. If the upstream node desires to make the 123 downstream node aware of its limitations with respect to label 124 selection, it MUST specify a list of valid labels via the LABEL_SET 125 object as specified in [RFC3473]. 127 In response, the downstream node picks an appropriate symmetric label 128 and sends it via the LABEL object in the RESV message. The upstream 129 node would then start using this symmetric label for both directions 130 of the LSP. If the downstream node cannot pick the symmetric label, 131 it MUST issue a PATH-ERR message with a "Routing Problem/Unacceptable 132 Label Value" indication. 134 The upstream node will continue to signal the Unassigned Upstream 135 Label in the PATH message even after it receives an appropriate 136 symmetric label in the RESV message. This is done to make sure that 137 the downstream node would pick a different symmetric label if and 138 when it needs to change the label at a later point in time. If the 139 upstream node receives an unacceptable changed label, then the error 140 procedure defined in [RFC3473] MUST be followed. 142 +----------+ +------------+ 143 ---| Upstream |--------------------| Downstream |--- 144 +----------+ +------------+ 146 PATH 147 Upstream Label (Unassigned) 148 Label-Set (L1, L2 ... Ln) 149 -------------------> 151 RESV 152 Label (Assigned - L2) 153 <------------------- 155 Unassigned UPSTREAM_LABEL 157 Figure 1 159 2.2. Backwards Compatibility 161 If the downstream node is running an implementation that doesn't 162 support the semantics of an Unassigned UPSTREAM LABEL, it will either 163 (a) reject the special label value and generate an error as specified 164 in Section 3.1 of [RFC3473] or (b) accept it and treat it as a valid 165 label. 167 If the behavior that is exhibited is (a), then there are obviously no 168 backwards compatibility concerns. If there is some existing 169 implementation that exhibits the behavior in (b), then there could be 170 some potential issues. However, at the time of publication, there is 171 no documented evidence of any existing implementation that uses the 172 "all-ones" bit pattern as a valid label. Thus, it is safe to assume 173 that the behavior in (b) will never be exhibited. 175 3. Use-Case: Wavelength Setup for IP over Optical Networks 177 Consider the network topology depicted in Figure 2. Nodes A and B 178 are client IP routers that are connected to an optical WDM transport 179 network. F and I represent WDM nodes. The transponder sits on the 180 router and is directly connected to the add-drop port on a WDM node. 182 The optical signal originating on "Router A" is tuned to a particular 183 wavelength. On "WDM-Node F", it gets multiplexed with optical 184 signals at other wavelengths. Depending on the implementation of 185 this multiplexing function, it may not be acceptable to have the 186 router send signal into the optical network unless it is at the 187 appropriate wavelength. In other words, having the router send 188 signal with a wrong wavelength may adversely impact existing optical 189 trails. If the clients do not have full visibility into the optical 190 network, they are not in a position to pick the correct wavelength 191 up-front. 193 The rest of this section examines how the protocol mechanism proposed 194 in this document allows the optical network to select and communicate 195 the correct wavelength to its clients. 197 3.1. Initial Setup 199 +---+ /-\ /-\ +---+ 200 | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | 201 +---+ \-/ \-/ +---+ 203 PATH 204 Upstream Label (Unassigned/0xFFFFFFFF) 205 ---------------------> 206 -- ~~ -- ~~ --> 207 PATH 208 --------------------> 209 RESV 210 <-------------------- 211 <-- ~~ -- ~~ -- 212 RESV 213 Label (Assigned) 214 <--------------------- 216 Initial Setup Sequence 218 Figure 2 220 Steps: 222 o "Router A" does not have enough information to pick an appropriate 223 client wavelength. It sends a PATH message downstream requesting 224 the network to assign an appropriate symmetric label for its use. 225 Since the client wavelength is unknown, the laser is off at the 226 ingress client. 228 o The downstream node (Node F) receives the PATH message, chooses 229 the appropriate wavelength values and forwards them in appropriate 230 label fields to the egress client ("Router B") 232 o "Router B" receives the PATH message, turns the laser ON and tunes 233 it to the appropriate wavelength (received in the UPSTREAM_LABEL/ 234 LABEL_SET of the PATH) and sends out a RESV message upstream. 236 o The RESV message received by the ingress client carries a valid 237 symmetric label in the LABEL object. "Router A" turns on the 238 laser and tunes it to the wavelength specified in the network 239 assigned symmetric LABEL. 241 For cases where the egress-node relies on RSVP signaling to determine 242 exactly when to start using the LSP, implementations may choose to 243 integrate the above sequence with any of the existing graceful setup 244 procedures: 246 o "RESV-CONF" setup procedure ([RFC2205]) 248 o 2-step "ADMIN STATUS" based setup procedure ("A" bit set in the 249 first step; "A" bit cleared when the LSP is ready for use). 250 ([RFC3473]) 252 3.2. Wavelength Change 254 After the LSP is set up, the network may decide to change the 255 wavelength for the given LSP. This could be for a variety of reasons 256 - policy reasons, restoration within the core, preemption etc. 258 In such a scenario, if the ingress client receives a changed label 259 via the LABEL object in a RESV modify, it retunes the laser at the 260 ingress to the new wavelength. Similarly, if the egress client 261 receives a changed label via UPSTREAM_LABEL/LABEL_SET in a PATH 262 modify, it retunes the laser at the egress to the new wavelength. 264 4. Acknowledgements 266 The authors would like to thank Adrian Farrel and Chris Bowers for 267 their inputs. 269 5. Contributors 271 John Drake 272 Juniper Networks 273 Email: jdrake@juniper.net 275 Gert Grammel 276 Juniper Networks 277 Email: ggrammel@juniper.net 279 Pawel Brzozowski 280 ADVA Optical Networking 281 Email: pbrzozowski@advaoptical.com 283 Zafar Ali 284 Cisco Systems, Inc. 285 Email: zali@cisco.com 287 6. IANA Considerations 289 This document makes no requests for IANA action. 291 7. Security Considerations 293 This document defines a special label value to be carried in the 294 UPSTREAM_LABEL object of a PATH message. This special label value is 295 used to enable the function of requesting network assignment of an 296 upstream label. The changes proposed in this document pertain to the 297 semantics of a specific field in an existing RSVP object and the 298 corresponding procedures. Thus, there are no new security 299 implications raised by this document and the security considerations 300 put together by [RFC3473] still applies. 302 For a general discussion on MPLS and GMPLS related security issues, 303 see the MPLS/GMPLS security framework [RFC5920]. 305 8. References 307 8.1. Normative References 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, 311 DOI 10.17487/RFC2119, March 1997, 312 . 314 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 315 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 316 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 317 September 1997, . 319 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 320 Switching (GMPLS) Signaling Resource ReserVation Protocol- 321 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 322 DOI 10.17487/RFC3473, January 2003, 323 . 325 8.2. Informative References 327 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 328 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 329 . 331 Authors' Addresses 333 Xian Zhang (editor) 334 Huawei Technologies 336 Email: zhang.xian@huawei.com 338 Vishnu Pavan Beeram (editor) 339 Juniper Networks 341 Email: vbeeram@juniper.net 343 Igor Bryskin 344 Huawei Technologies 346 Email: igor.bryskin@huawei.com 348 Daniele Ceccarelli 349 Ericsson 351 Email: daniele.ceccarelli@ericsson.com 353 Oscar Gonzalez de Dios 354 Telefonica 356 Email: ogondio@tid.es