Network-Assigned Upstream Label
A special all-ones label lets a GMPLS node ask the next node downstream to pick the upstream label for it.
Zhang, X., Ed., Beeram, V., Ed., Bryskin, I., Ceccarelli, D., and O. Gonzalez de Dios, "Network-Assigned Upstream Label", RFC 8359, DOI 10.17487/RFC8359, March 2018, <https://www.rfc-editor.org/info/rfc8359>.
@misc{rfc8359,
series = {Request for Comments},
number = 8359,
howpublished = {RFC 8359},
publisher = {RFC Editor},
doi = {10.17487/RFC8359},
url = {https://www.rfc-editor.org/info/rfc8359},
author = {X. Zhang and V. Beeram and I. Bryskin and D. Ceccarelli and O. Gonzalez de Dios},
title = {{Network-Assigned Upstream Label}},
pagetotal = 10,
year = 2018,
month = mar,
} RFC text
Contents
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.
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.
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.
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.
+----------+ +------------+
---| 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.
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.
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
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>.
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
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
AI ELI5
On this page
§1The Problem with Self-Chosen Labels
A bidirectional Label Switched Path (LSP) in GMPLS is set up with RSVP-TE. It is indicated by an UPSTREAM_LABEL object in the Path message. Under the existing procedure in RFC 3471 and RFC 3473, each upstream node must allocate a valid upstream label on its outgoing interface before it sends the first Path message downstream.
In some scenarios it is not desirable or possible for a node to pick that label on its own. This RFC defines a mechanism that lets the node hand the job to nodes downstream. It is meant only for bidirectional LSPs that use symmetric labels at each hop, such as Lambda Switch Capable (LSC) LSPs, which use symmetric lambda labels as in RFC 6205.
Normally the sender must choose the channel before it starts talking. Sometimes the sender simply does not know which channel is safe, so it needs help.
§3The Unassigned Upstream Label
The RFC defines a special label value, 0xFFFFFFFF for a 4-octet label, called the Unassigned Upstream Label. Similar all-ones patterns are expected for labels of other sizes.
When this value appears in the UPSTREAM_LABEL object of a Path message, it means the upstream node has not assigned an upstream label and asks the downstream node for a label usable in both the forward and reverse directions. The receiving node MUST also read it as a request to mandate symmetric labels for the LSP.
This changes two earlier rules. The UPSTREAM_LABEL may now carry a label that is not valid for forwarding, and in the LSC case it may differ from the value in the LABEL_SET object, which RFC 6205 required to be the same.
A secret code, all ones, means 'I have not picked yet, please pick for both of us'. It is not a real channel.
§3.1Signaling Procedures
The procedures cover only the exchange between an upstream node and its immediate downstream node. The upstream node sends a Path message with the Unassigned Upstream Label. If it wants to tell the downstream node about its limits, it MUST list the valid labels in a LABEL_SET object.
The downstream node picks a symmetric label and returns it in the LABEL object of the Resv message, and the upstream node then uses it in both directions. If the downstream node cannot pick one, it MUST send a PathErr message with a 'Routing Problem/Unacceptable Label Value' indication. If the upstream node gets back an all-ones label or any other unacceptable label, it MUST send a ResvErr with the same indication.
The upstream node keeps signaling the Unassigned Upstream Label even after it receives a label. This lets the downstream node choose a different symmetric label later. An unacceptable changed label again triggers a ResvErr.
You ask, your friend answers with a channel, and you both use it. If your friend cannot find one, or gives you a bad one, someone says 'that will not work'.
- PathUpstream Label (Unassigned), Label-Set (L1, L2 ... Ln)
- ResvLabel (Assigned - L2)
§3.2Backwards Compatibility
A downstream node that does not understand the new meaning will do one of two things. It may reject the special value with an error as in Section 3.1 of RFC 3473, in which case there is no compatibility concern.
Or it may accept the value as if it were a valid label. Then it will send an all-ones label in the LABEL object of the Resv message, and the upstream node answers with a ResvErr carrying 'Routing Problem/Unacceptable Label Value'.
If your friend does not know the 'you choose' game, either they say so, or they answer with the secret code. Then you tell them it is not a real answer.
§4Use Case: Wavelength Setup over Optical Networks
Routers A and B are clients of an optical WDM network, with WDM nodes F and I between them. A router's transponder is wired to an add-drop port on a WDM node. Depending on how multiplexing is implemented, a router sending the wrong wavelength may harm existing optical trails, and a client without full view of the optical network cannot pick the right one in advance.
In the initial setup, Router A sends a Path message with the Unassigned Upstream Label, and its laser stays off because the wavelength is unknown. Node F chooses the wavelength and forwards it in the label fields toward Router B. Router B turns its laser on and tunes it to that wavelength, then sends a Resv upstream. Router A receives a valid symmetric label in the LABEL object and then tunes and turns on its own laser.
Later, the network may change the wavelength for reasons such as policy, restoration within the core or preemption. Each client then retunes its laser when it receives the changed label in a modified Resv or Path message. Where the egress relies on signaling to know when to start using the LSP, the sequence can be combined with the ResvConf procedure of RFC 2205 or the two-step ADMIN STATUS procedure of RFC 3473.
A router is like a flashlight that must be set to the right color before turning on. It waits, the network tells it the color, then it switches on. If the network later changes the color, it retunes.
§5IANA and Security
IANA added a new subregistry, 'Special Purpose Generalized Label Values', to the GMPLS Signaling Parameters registry. New values are assigned by Standards Action. The first entry is the all-ones pattern, named Unassigned Upstream Label, applicable to UPSTREAM_LABEL.
On security, the RFC says the change only affects the meaning of one field in an existing RSVP object, so it raises no new security implications and the considerations in RFC 3473 still apply. It points to RFC 5920 for general MPLS and GMPLS security.
The special code is written in an official list so nobody uses it for something else. It adds no new dangers.