Internet Engineering Task Force (IETF) X. Zhang, Ed. Request for Comments: 8359 Huawei Technologies Updates: 3471, 3473, 6205 V. Beeram, Ed. Category: Standards Track Juniper Networks ISSN: 2070-1721 I. Bryskin Huawei Technologies D. Ceccarelli Ericsson O. Gonzalez de Dios Telefonica March 2018 Network-Assigned Upstream Label
AbstractThis document discusses a Generalized Multi-Protocol Label Switching (GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP-TE) mechanism that enables the network to assign an upstream label for a bidirectional Label Switched Path (LSP). This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream label on its own and needs to rely on the downstream node to pick an appropriate label. This document updates RFCs 3471, 3473, and 6205 as it defines processing for a special label value in the UPSTREAM_LABEL object. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8359.
Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Unassigned Upstream Label . . . . . . . . . . . . . . . . . . 3 3.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 5 4. Use-Case: Wavelength Setup for IP over Optical Networks . . . 5 4.1. Initial Setup . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Wavelength Change . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 RFC3471]. The GMPLS Resource reSerVation Protocol with Traffic Engineering (RSVP-TE) extensions for setting up a bidirectional LSP are specified in [RFC3473]. The bidirectional LSP setup is indicated by the presence of an UPSTREAM_LABEL object in the Path message. As per the existing setup procedure outlined for a bidirectional LSP, each upstream node must allocate a valid upstream label on the outgoing interface before sending the initial Path message downstream. However, there are certain scenarios (see Section 4) where it is not desirable or possible for a given node to pick the upstream label on its own.
This document defines the protocol mechanism to be used in such scenarios. This mechanism enables a given node to offload the task of assigning the upstream label for a given bidirectional LSP to nodes downstream in the network. It is meant to be used only for bidirectional LSPs that assign symmetric labels at each hop along the path of the LSP. Bidirectional Lambda Switch Capable (LSC) LSPs use symmetric lambda labels (format specified in [RFC6205]) at each hop along the path of the LSP. As per the bidirectional LSP setup procedures specified in [RFC3471] and [RFC3473], the UPSTREAM_LABEL object must indicate a label that is valid for forwarding. This document updates that by allowing the UPSTREAM_LABEL object to indicate a special label that isn't valid for forwarding. As per the bidirectional LSC LSP setup procedures specified in [RFC6205], the LABEL_SET object and the UPSTREAM_LABEL object must contain the same label value. This document updates that by allowing the UPSTREAM_LABEL object to carry a special label value that is different from the one used in the LABEL_SET object. RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Unassigned UPSTREAM_LABEL - "all-ones" Pattern The presence of this value in the UPSTREAM_LABEL object of a Path message indicates that the upstream node has not assigned an upstream label on its own and has requested the downstream node to provide a label that it can use in both the forward and reverse directions.
The presence of this value in the UPSTREAM_LABEL object of a Path message MUST also be interpreted by the receiving node as a request to mandate symmetric labels for the LSP. RFC3473]. In response, the downstream node picks an appropriate symmetric label and sends it via the LABEL object in the Resv message. The upstream node would then start using this symmetric label for both directions of the LSP. If the downstream node cannot pick the symmetric label, it MUST issue a PathErr message with a "Routing Problem/Unacceptable Label Value" indication. If the upstream node that signals an Unassigned Upstream Label receives a label with the "all-ones" pattern or any other unacceptable label in the LABEL object of the Resv message, it MUST issue a ResvErr message with a "Routing Problem/Unacceptable Label Value" indication. The upstream node will continue to signal the Unassigned Upstream Label in the Path message even after it receives an appropriate symmetric label in the Resv message. This is done to make sure that the downstream node would pick a different symmetric label if and when it needs to change the label at a later time. If the upstream node receives an unacceptable changed label, then it MUST issue a ResvErr message with a "Routing Problem/Unacceptable Label Value" indication.
+----------+ +------------+ ---| Upstream |--------------------| Downstream |--- +----------+ +------------+ Path Upstream Label (Unassigned) Label-Set (L1, L2 ... Ln) -------------------> Resv Label (Assigned - L2) <------------------- Figure 2: Signaling Sequence Section 3.1 of [RFC3473] or (b) accept it and treat it as a valid label. If the behavior that is exhibited is (a), then there are no backwards compatibility concerns. If the behavior that is exhibited is (b), then the downstream node will send a label with the "all-ones" pattern in the LABEL object of the Resv message. In response, the upstream node will issue a ResvErr message with a "Routing Problem/ Unacceptable Label Value" indication. Figure 3. Nodes A and B are client IP routers that are connected to an optical Wavelength Division Multiplexing (WDM) transport network. F and I represent WDM nodes. The transponder sits on the router and is directly connected to the add-drop port on a WDM node. The optical signal originating on "Router A" is tuned to a particular wavelength. On "WDM-Node F", it gets multiplexed with optical signals at other wavelengths. Depending on the implementation of this multiplexing function, it may not be acceptable to have the router send the signal into the optical network unless it is at the appropriate wavelength. In other words, having the router send signals with a wrong wavelength may adversely impact existing optical trails. If the clients do not have full visibility into the optical network, they are not in a position to pick the correct wavelength in advance.
The rest of this section examines how the protocol mechanism proposed in this document allows the optical network to select and communicate the correct wavelength to its clients. +---+ /-\ /-\ +---+ | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | +---+ \-/ \-/ +---+ Path Upstream Label (Unassigned/0xFFFFFFFF) ---------------------> -- ~~ -- ~~ --> Path --------------------> Resv <-------------------- <-- ~~ -- ~~ -- Resv Label (Assigned) <--------------------- Figure 3: Initial Setup Sequence Steps: o "Router A" does not have enough information to pick an appropriate client wavelength. It sends a Path message downstream requesting the network to assign an appropriate symmetric label for its use. Since the client wavelength is unknown, the laser is off at the ingress client. o The downstream node (Node F) receives the Path message, chooses the appropriate wavelength values, and forwards them in appropriate label fields to the egress client ("Router B"). o "Router B" receives the Path message, turns the laser ON and tunes it to the appropriate wavelength (received in the UPSTREAM_LABEL/ LABEL_SET of the Path) and sends a Resv message upstream. o The Resv message received by the ingress client carries a valid symmetric label in the LABEL object. "Router A" turns on the laser and tunes it to the wavelength specified in the network assigned symmetric LABEL.
For cases where the egress-node relies on RSVP signaling to determine exactly when to start using the LSP, implementations may choose to integrate the above sequence with any of the existing graceful setup procedures: o "ResvConf" setup procedure ([RFC2205]) o Two-step "ADMIN STATUS" based setup procedure ("A" bit set in the first step; "A" bit cleared when the LSP is ready for use) ([RFC3473]) RFC8126]. Special Purpose Generalized Label Values Pattern/ Label Name Applicable Reference Value Objects -------- ---------------- -------------- ---------- all-ones Unassigned UPSTREAM_LABEL [RFC8359] Upstream Label
corresponding procedures. Thus, there are no new security implications raised by this document and the security considerations discussed by [RFC3473] still apply. For a general discussion on MPLS and GMPLS related security issues, see the MPLS/GMPLS security framework [RFC5920]. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>. [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, <https://www.rfc-editor.org/info/rfc3471>. [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>. [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 6205, DOI 10.17487/RFC6205, March 2011, <https://www.rfc-editor.org/info/rfc6205>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.