summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8359.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8359.txt')
-rw-r--r--doc/rfc/rfc8359.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc8359.txt b/doc/rfc/rfc8359.txt
new file mode 100644
index 0000000..0d78688
--- /dev/null
+++ b/doc/rfc/rfc8359.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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
+
+Abstract
+
+ This 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.
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 1]
+
+RFC 8359 Network Assigned Upstream-Label March 2018
+
+
+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.
+
+Table of Contents
+
+ 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
+
+1. Introduction
+
+ A functional description of the Generalized Multi-Protocol Label
+ Switching (GMPLS) signaling extensions for setting up a bidirectional
+ Label Switched Path (LSP) is provided in [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.
+
+
+
+Zhang, et al. Standards Track [Page 2]
+
+RFC 8359 Network Assigned Upstream-Label March 2018
+
+
+ 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.
+
+2. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+3. Unassigned Upstream Label
+
+ This document defines a special label value -- "0xFFFFFFFF" (for a
+ 4-octet label) -- to indicate an Unassigned Upstream Label. Similar
+ "all-ones" patterns are expected to be used for labels of other
+ sizes.
+
+ 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.
+
+
+
+
+Zhang, et al. Standards Track [Page 3]
+
+RFC 8359 Network Assigned Upstream-Label March 2018
+
+
+ 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.
+
+3.1. Procedures
+
+ The scope of the procedures is limited to the exchange and processing
+ of messages between an upstream node and its immediate downstream
+ node. The Unassigned Upstream Label is used by an upstream node when
+ it is not in a position to pick the upstream label on its own. In
+ such a scenario, the upstream node sends a Path message downstream
+ with an Unassigned Upstream Label and requests the downstream node to
+ provide a symmetric label. If the upstream node desires to make the
+ downstream node aware of its limitations with respect to label
+ selection, it MUST specify a list of valid labels via the LABEL_SET
+ object as specified in [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 4]
+
+RFC 8359 Network Assigned Upstream-Label March 2018
+
+
+ +----------+ +------------+
+ ---| Upstream |--------------------| Downstream |---
+ +----------+ +------------+
+
+ Path
+ Upstream Label (Unassigned)
+ Label-Set (L1, L2 ... Ln)
+ ------------------->
+
+ Resv
+ Label (Assigned - L2)
+ <-------------------
+
+ Figure 2: Signaling Sequence
+
+3.2. Backwards Compatibility
+
+ If the downstream node is running an implementation that doesn't
+ support the semantics of an Unassigned UPSTREAM LABEL, it will either
+ (a) reject the special label value and generate an error as specified
+ in 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.
+
+4. Use-Case: Wavelength Setup for IP over Optical Networks
+
+ Consider the network topology depicted in 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.
+
+
+
+Zhang, et al. Standards Track [Page 5]
+
+RFC 8359 Network Assigned Upstream-Label March 2018
+
+
+ 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.
+
+4.1. Initial Setup
+
+ +---+ /-\ /-\ +---+
+ | 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.
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 6]
+
+RFC 8359 Network Assigned Upstream-Label March 2018
+
+
+ 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])
+
+4.2. Wavelength Change
+
+ After the LSP is set up, the network may decide to change the
+ wavelength for the given LSP. This could be for a variety of reasons
+ including policy reasons, restoration within the core, preemption,
+ etc.
+
+ In such a scenario, if the ingress client receives a changed label
+ via the LABEL object in a modified Resv message, it retunes the laser
+ at the ingress to the new wavelength. Similarly, if the egress
+ client receives a changed label via UPSTREAM_LABEL/LABEL_SET in a
+ modified Path message, it retunes the laser at the egress to the new
+ wavelength.
+
+5. IANA Considerations
+
+ IANA maintains the "Generalized Multi-Protocol Label Switching
+ (GMPLS) Signaling Parameters" registry. IANA has added a new
+ subregistry titled "Special Purpose Generalized Label Values". New
+ values are assigned according to Standards Action [RFC8126].
+
+ Special Purpose Generalized Label Values
+
+ Pattern/ Label Name Applicable Reference
+ Value Objects
+ -------- ---------------- -------------- ----------
+ all-ones Unassigned UPSTREAM_LABEL [RFC8359]
+ Upstream Label
+
+6. Security Considerations
+
+ This document defines a special label value to be carried in the
+ UPSTREAM_LABEL object of a Path message. This special label value is
+ used to enable the function of requesting network assignment of an
+ upstream label. The changes proposed in this document pertain to the
+ semantics of a specific field in an existing RSVP object and the
+
+
+
+
+Zhang, et al. Standards Track [Page 7]
+
+RFC 8359 Network Assigned Upstream-Label March 2018
+
+
+ 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].
+
+7. References
+
+7.1. Normative References
+
+ [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>.
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 8]
+
+RFC 8359 Network Assigned Upstream-Label March 2018
+
+
+7.2. Informative References
+
+ [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>.
+
+Acknowledgements
+
+ The authors would like to thank Adrian Farrel and Chris Bowers for
+ their inputs.
+
+Contributors
+
+ John Drake
+ Juniper Networks
+ Email: jdrake@juniper.net
+
+ Gert Grammel
+ Juniper Networks
+ Email: ggrammel@juniper.net
+
+ Pawel Brzozowski
+ ADVA Optical Networking
+ Email: pbrzozowski@advaoptical.com
+
+ Zafar Ali
+ Cisco Systems, Inc.
+ Email: zali@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 9]
+
+RFC 8359 Network Assigned Upstream-Label March 2018
+
+
+Authors' Addresses
+
+ Xian Zhang (editor)
+ Huawei Technologies
+
+ Email: zhang.xian@huawei.com
+
+
+ Vishnu Pavan Beeram (editor)
+ Juniper Networks
+
+ Email: vbeeram@juniper.net
+
+
+ Igor Bryskin
+ Huawei Technologies
+
+ Email: igor.bryskin@huawei.com
+
+
+ Daniele Ceccarelli
+ Ericsson
+
+ Email: daniele.ceccarelli@ericsson.com
+
+
+ Oscar Gonzalez de Dios
+ Telefonica
+
+ Email: ogondio@tid.es
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 10]
+