draft-ietf-teas-network-assigned-upstream-label-08.txt   draft-ietf-teas-network-assigned-upstream-label-09.txt 
TEAS Working Group X. Zhang, Ed. TEAS Working Group X. Zhang, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Updates: 3473 (if approved) V. Beeram, Ed. Updates: 3471, 3473, 6205 (if approved) V. Beeram, Ed.
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: February 12, 2018 I. Bryskin Expires: May 3, 2018 I. Bryskin
Huawei Technologies Huawei Technologies
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
O. Gonzalez de Dios O. Gonzalez de Dios
Telefonica Telefonica
August 11, 2017 October 30, 2017
Network Assigned Upstream-Label Network Assigned Upstream-Label
draft-ietf-teas-network-assigned-upstream-label-08 draft-ietf-teas-network-assigned-upstream-label-09
Abstract Abstract
This document discusses a Generalized Multi-Protocol Label Switching This document discusses a Generalized Multi-Protocol Label Switching
(GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP- (GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP-
TE) mechanism that enables the network to assign an upstream label TE) mechanism that enables the network to assign an upstream label
for a bidirectional Label Switched Path (LSP). This is useful in for a bidirectional Label Switched Path (LSP). This is useful in
scenarios where a given node does not have sufficient information to 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 assign the correct upstream label on its own and needs to rely on the
downstream node to pick an appropriate label. This document updates downstream node to pick an appropriate label. This document updates
RFC3473. RFCs 3471, 3473 and 6205 as it defines processing for a special label
value in the UPSTREAM_LABEL object.
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 12, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Unassigned Upstream Label . . . . . . . . . . . . . . . . . . 3 2. Unassigned Upstream Label . . . . . . . . . . . . . . . . . . 3
2.1. Processing Rules . . . . . . . . . . . . . . . . . . . . 3 2.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 4 2.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 5
3. Use-Case: Wavelength Setup for IP over Optical Networks . . . 4 3. Use-Case: Wavelength Setup for IP over Optical Networks . . . 5
3.1. Initial Setup . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Initial Setup . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Wavelength Change . . . . . . . . . . . . . . . . . . . . 6 3.2. Wavelength Change . . . . . . . . . . . . . . . . . . . . 7
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The Generalized Multi-Protocol Label Switching (GMPLS) Resource A functional description of the Generalized Multi-Protocol Label
reSerVation Protocol with Traffic Engineering (RSVP-TE) extensions Switching (GMPLS) signaling extensions for setting up a bidirectional
for setting up a bidirectional Label Switched Path (LSP) are Label Switched Path (LSP) is provided in [RFC3471]. The GMPLS
specified in [RFC3473]. The bidirectional LSP setup is indicated by Resource reSerVation Protocol with Traffic Engineering (RSVP-TE)
the presence of an UPSTREAM_LABEL Object in the PATH message. As per extensions for setting up a bidirectional LSP are specified in
the existing setup procedure outlined for a bidirectional LSP, each [RFC3473]. The bidirectional LSP setup is indicated by the presence
upstream node must allocate a valid upstream label on the outgoing of an UPSTREAM_LABEL object in the PATH message. As per the existing
interface before sending the initial PATH message downstream. setup procedure outlined for a bidirectional LSP, each upstream node
However, there are certain scenarios where it is not desirable or must allocate a valid upstream label on the outgoing interface before
possible for a given node to pick the upstream label on its own. sending the initial PATH message downstream. However, there are
This document defines the protocol mechanism to be used in such certain scenarios where it is not desirable or possible for a given
scenarios. This mechanism enables a given node to offload the task node to pick the upstream label on its own. This document defines
of assigning the upstream label for a given bidirectional LSP to the protocol mechanism to be used in such scenarios. This mechanism
nodes downstream in the network. It is meant to be used only for enables a given node to offload the task of assigning the upstream
bidirectional LSPs that assign symmetric labels at each hop along the label for a given bidirectional LSP to nodes downstream in the
path of the LSP. This document updates [RFC3473] as it defines network. It is meant to be used only for bidirectional LSPs that
processing for a special label value. assign symmetric labels at each hop along the path of the LSP.
Bidirectional Lambda Switch Capable (LSC) LSPs use symmetric lambda
1.1. Requirements Language labels (format specified in [RFC6205]) at each hop along the path of
the LSP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", As per the bidirectional LSP setup procedures specified in [RFC3471]
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this and [RFC3473], the UPSTREAM_LABEL object must indicate a label that
document are to be interpreted as described in [RFC2119]. 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 UPSREAM_LABEL object to carry a special label value
that is different from the one used in the LABEL_SET object.
2. Unassigned Upstream Label 2. Unassigned Upstream Label
This document proposes the use of a special label value - This document defines a special label value - "0xFFFFFFFF" (for a
"0xFFFFFFFF" (for a 4-octet label) - to indicate an Unassigned 4-octet label) - to indicate an Unassigned Upstream Label. Similar
Upstream Label. Similar "all-ones" patterns are expected to be used "all-ones" patterns are expected to be used for labels of other
for labels of other sizes. The presence of this value in the sizes.
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.
2.1. Processing Rules 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|
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Unassigned Upstream Label is used by an upstream node when it is Figure 1: Unassigned UPSTREAM_LABEL - "all-ones" Pattern
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 The presence of this value in the UPSTREAM_LABEL object of a PATH
Unassigned Upstream Label and requests the downstream node to provide message indicates that the upstream node has not assigned an upstream
a symmetric label. If the upstream node desires to make the 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.
2.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 downstream node aware of its limitations with respect to label
selection, it MUST specify a list of valid labels via the LABEL_SET selection, it MUST specify a list of valid labels via the LABEL_SET
object as specified in [RFC3473]. object as specified in [RFC3473].
In response, the downstream node picks an appropriate symmetric label In response, the downstream node picks an appropriate symmetric label
and sends it via the LABEL object in the RESV message. The upstream and sends it via the LABEL object in the RESV message. The upstream
node would then start using this symmetric label for both directions node would then start using this symmetric label for both directions
of the LSP. If the downstream node cannot pick the symmetric label, of the LSP. If the downstream node cannot pick the symmetric label,
it MUST issue a PATH-ERR message with a "Routing Problem/Unacceptable it MUST issue a PATH-ERR message with a "Routing Problem/Unacceptable
Label Value" indication. Label Value" indication. If the upstream node that signals an
Unassigned Upstream Label receives a label with the "all-ones"
pattern in the LABEL object of the RESV message, it MUST issue a
RESV-ERR message with a "Routing Problem/Unacceptable Label"
indication.
The upstream node will continue to signal the Unassigned Upstream The upstream node will continue to signal the Unassigned Upstream
Label in the PATH message even after it receives an appropriate Label in the PATH message even after it receives an appropriate
symmetric label in the RESV message. This is done to make sure that symmetric label in the RESV message. This is done to make sure that
the downstream node would pick a different symmetric label if and 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 when it needs to change the label at a later time. If the upstream
node receives an unacceptable changed label, then the error procedure node receives an unacceptable changed label, then it MUST issue a
defined in [RFC3473] MUST be followed. RESV-ERR message with a "Routing Problem/Unacceptable Label"
indication.
+----------+ +------------+ +----------+ +------------+
---| Upstream |--------------------| Downstream |--- ---| Upstream |--------------------| Downstream |---
+----------+ +------------+ +----------+ +------------+
PATH PATH
Upstream Label (Unassigned) Upstream Label (Unassigned)
Label-Set (L1, L2 ... Ln) Label-Set (L1, L2 ... Ln)
-------------------> ------------------->
RESV RESV
Label (Assigned - L2) Label (Assigned - L2)
<------------------- <-------------------
Unassigned UPSTREAM_LABEL Figure 2: Signaling Sequence
Figure 1
2.2. Backwards Compatibility 2.2. Backwards Compatibility
If the downstream node is running an implementation that doesn't If the downstream node is running an implementation that doesn't
support the semantics of an Unassigned UPSTREAM LABEL, it will either support the semantics of an Unassigned UPSTREAM LABEL, it will either
(a) reject the special label value and generate an error as specified (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 in Section 3.1 of [RFC3473] or (b) accept it and treat it as a valid
label. label.
If the behavior that is exhibited is (a), then there are obviously no If the behavior that is exhibited is (a), then there are no backwards
backwards compatibility concerns. If there is some existing compatibility concerns. If the behavior that is exhibited is (b),
implementation that exhibits the behavior in (b), then there could be then the downstream node will send a label with the "all-ones"
some potential issues. However, at the time of publication, there is pattern in the LABEL object of the RESV message. In response, the
no documented evidence of any existing implementation that uses the upstream node will issue a RESV-ERR message with a "Routing Problem/
"all-ones" bit pattern as a valid label. Thus, it is safe to assume Unassigned Label" indication.
that the behavior in (b) will never be exhibited.
3. Use-Case: Wavelength Setup for IP over Optical Networks 3. Use-Case: Wavelength Setup for IP over Optical Networks
Consider the network topology depicted in Figure 2. Nodes A and B Consider the network topology depicted in Figure 3. Nodes A and B
are client IP routers that are connected to an optical Wavelength are client IP routers that are connected to an optical Wavelength
Division Multiplexing (WDM) transport network. F and I represent WDM Division Multiplexing (WDM) transport network. F and I represent WDM
nodes. The transponder sits on the router and is directly connected nodes. The transponder sits on the router and is directly connected
to the add-drop port on a WDM node. to the add-drop port on a WDM node.
The optical signal originating on "Router A" is tuned to a particular The optical signal originating on "Router A" is tuned to a particular
wavelength. On "WDM-Node F", it gets multiplexed with optical wavelength. On "WDM-Node F", it gets multiplexed with optical
signals at other wavelengths. Depending on the implementation of signals at other wavelengths. Depending on the implementation of
this multiplexing function, it may not be acceptable to have the this multiplexing function, it may not be acceptable to have the
router send the signal into the optical network unless it is at the router send the signal into the optical network unless it is at the
skipping to change at page 5, line 36 skipping to change at page 6, line 21
-- ~~ -- ~~ --> -- ~~ -- ~~ -->
PATH PATH
--------------------> -------------------->
RESV RESV
<-------------------- <--------------------
<-- ~~ -- ~~ -- <-- ~~ -- ~~ --
RESV RESV
Label (Assigned) Label (Assigned)
<--------------------- <---------------------
Initial Setup Sequence Figure 3: Initial Setup Sequence
Figure 2
Steps: Steps:
o "Router A" does not have enough information to pick an appropriate o "Router A" does not have enough information to pick an appropriate
client wavelength. It sends a PATH message downstream requesting client wavelength. It sends a PATH message downstream requesting
the network to assign an appropriate symmetric label for its use. the network to assign an appropriate symmetric label for its use.
Since the client wavelength is unknown, the laser is off at the Since the client wavelength is unknown, the laser is off at the
ingress client. ingress client.
o The downstream node (Node F) receives the PATH message, chooses o The downstream node (Node F) receives the PATH message, chooses
skipping to change at page 7, line 18 skipping to change at page 7, line 47
Pawel Brzozowski Pawel Brzozowski
ADVA Optical Networking ADVA Optical Networking
Email: pbrzozowski@advaoptical.com Email: pbrzozowski@advaoptical.com
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
Email: zali@cisco.com Email: zali@cisco.com
6. IANA Considerations 6. IANA Considerations
This document makes no requests for IANA action. IANA maintains the "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Parameters" registry. IANA is requested to add a
new subregistry for "Special Purpose Generalized Label Values". New
values are assigned according to Standards Action.
Special Purpose Generalized Label Values
Pattern/ Label Name Applicable Reference
Value Objects
-------- ---------------- -------------- ----------
all-ones Unassigned UPSTREAM_LABEL [This.I-D]
Upstream Label
7. Security Considerations 7. Security Considerations
This document defines a special label value to be carried in the This document defines a special label value to be carried in the
UPSTREAM_LABEL object of a PATH message. This special label value is UPSTREAM_LABEL object of a PATH message. This special label value is
used to enable the function of requesting network assignment of an used to enable the function of requesting network assignment of an
upstream label. The changes proposed in this document pertain to the upstream label. The changes proposed in this document pertain to the
semantics of a specific field in an existing RSVP object and the semantics of a specific field in an existing RSVP object and the
corresponding procedures. Thus, there are no new security corresponding procedures. Thus, there are no new security
implications raised by this document and the security considerations implications raised by this document and the security considerations
skipping to change at page 7, line 40 skipping to change at page 8, line 33
For a general discussion on MPLS and GMPLS related security issues, For a general discussion on MPLS and GMPLS related security issues,
see the MPLS/GMPLS security framework [RFC5920]. see the MPLS/GMPLS security framework [RFC5920].
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <http://www.rfc-editor.org/info/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 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol- Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3473>. 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>.
8.2. Informative References 8.2. Informative References
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>. <https://www.rfc-editor.org/info/rfc5920>.
Authors' Addresses Authors' Addresses
Xian Zhang (editor) Xian Zhang (editor)
Huawei Technologies Huawei Technologies
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Vishnu Pavan Beeram (editor) Vishnu Pavan Beeram (editor)
Juniper Networks Juniper Networks
 End of changes. 26 change blocks. 
81 lines changed or deleted 133 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/