draft-ietf-teas-network-assigned-upstream-label-10.txt   draft-ietf-teas-network-assigned-upstream-label-11.txt 
TEAS Working Group X. Zhang, Ed. TEAS Working Group X. Zhang, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Updates: 3471, 3473, 6205 (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: June 18, 2018 I. Bryskin Expires: July 3, 2018 I. Bryskin
Huawei Technologies Huawei Technologies
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
O. Gonzalez de Dios O. Gonzalez de Dios
Telefonica Telefonica
December 15, 2017 December 30, 2017
Network Assigned Upstream-Label Network Assigned Upstream-Label
draft-ietf-teas-network-assigned-upstream-label-10 draft-ietf-teas-network-assigned-upstream-label-11
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
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 June 18, 2018. This Internet-Draft will expire on July 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Unassigned Upstream Label . . . . . . . . . . . . . . . . . . 3 2. Unassigned Upstream Label . . . . . . . . . . . . . . . . . . 3
2.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 5 2.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 5
3. Use-Case: Wavelength Setup for IP over Optical Networks . . . 5 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 . . . . . . . . . . . . . . . . . . . . 7 3.2. Wavelength Change . . . . . . . . . . . . . . . . . . . . 7
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
A functional description of the Generalized Multi-Protocol Label A functional description of the Generalized Multi-Protocol Label
Switching (GMPLS) signaling extensions for setting up a bidirectional Switching (GMPLS) signaling extensions for setting up a bidirectional
Label Switched Path (LSP) is provided in [RFC3471]. The GMPLS Label Switched Path (LSP) is provided in [RFC3471]. The GMPLS
Resource reSerVation Protocol with Traffic Engineering (RSVP-TE) Resource reSerVation Protocol with Traffic Engineering (RSVP-TE)
extensions for setting up a bidirectional LSP are specified in extensions for setting up a bidirectional LSP are specified in
[RFC3473]. The bidirectional LSP setup is indicated by the presence [RFC3473]. The bidirectional LSP setup is indicated by the presence
of an UPSTREAM_LABEL object in the Path message. As per the existing of an UPSTREAM_LABEL object in the Path message. As per the existing
setup procedure outlined for a bidirectional LSP, each upstream node setup procedure outlined for a bidirectional LSP, each upstream node
must allocate a valid upstream label on the outgoing interface before must allocate a valid upstream label on the outgoing interface before
sending the initial Path message downstream. However, there are sending the initial Path message downstream. However, there are
certain scenarios where it is not desirable or possible for a given certain scenarios (see Section 3) where it is not desirable or
node to pick the upstream label on its own. This document defines possible for a given node to pick the upstream label on its own.
the protocol mechanism to be used in such scenarios. This mechanism This document defines the protocol mechanism to be used in such
enables a given node to offload the task of assigning the upstream scenarios. This mechanism enables a given node to offload the task
label for a given bidirectional LSP to nodes downstream in the of assigning the upstream label for a given bidirectional LSP to
network. It is meant to be used only for bidirectional LSPs that nodes downstream in the network. It is meant to be used only for
assign symmetric labels at each hop along the path of the LSP. bidirectional LSPs that assign symmetric labels at each hop along the
Bidirectional Lambda Switch Capable (LSC) LSPs use symmetric lambda path of the LSP. Bidirectional Lambda Switch Capable (LSC) LSPs use
labels (format specified in [RFC6205]) at each hop along the path of symmetric lambda labels (format specified in [RFC6205]) at each hop
the LSP. along the path of the LSP.
As per the bidirectional LSP setup procedures specified in [RFC3471] As per the bidirectional LSP setup procedures specified in [RFC3471]
and [RFC3473], the UPSTREAM_LABEL object must indicate a label that and [RFC3473], the UPSTREAM_LABEL object must indicate a label that
is valid for forwarding. This document updates that by allowing the is valid for forwarding. This document updates that by allowing the
UPSTREAM_LABEL object to indicate a special label that isn't valid UPSTREAM_LABEL object to indicate a special label that isn't valid
for forwarding. As per the bidirectional LSC LSP setup procedures for forwarding. As per the bidirectional LSC LSP setup procedures
specified in [RFC6205], the LABEL_SET object and the UPSTREAM_LABEL specified in [RFC6205], the LABEL_SET object and the UPSTREAM_LABEL
object must contain the same label value. This document updates that object must contain the same label value. This document updates that
by allowing the UPSREAM_LABEL object to carry a special label value by allowing the UPSREAM_LABEL object to carry a special label value
that is different from the one used in the LABEL_SET object. that is different from the one used in the LABEL_SET object.
skipping to change at page 7, line 22 skipping to change at page 7, line 22
including policy reasons, restoration within the core, preemption, including policy reasons, restoration within the core, preemption,
etc. etc.
In such a scenario, if the ingress client receives a changed label 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 via the LABEL object in a modified Resv message, it retunes the laser
at the ingress to the new wavelength. Similarly, if the egress at the ingress to the new wavelength. Similarly, if the egress
client receives a changed label via UPSTREAM_LABEL/LABEL_SET in a 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 modified Path message, it retunes the laser at the egress to the new
wavelength. wavelength.
4. Acknowledgements 4. IANA Considerations
The authors would like to thank Adrian Farrel and Chris Bowers for
their inputs.
5. 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
6. IANA Considerations
IANA maintains the "Generalized Multi-Protocol Label Switching IANA maintains the "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Parameters" registry. IANA is requested to add a (GMPLS) Signaling Parameters" registry. IANA is requested to add a
new subregistry for "Special Purpose Generalized Label Values". New new subregistry for "Special Purpose Generalized Label Values". New
values are assigned according to Standards Action. values are assigned according to Standards Action.
Special Purpose Generalized Label Values Special Purpose Generalized Label Values
Pattern/ Label Name Applicable Reference Pattern/ Label Name Applicable Reference
Value Objects Value Objects
-------- ---------------- -------------- ---------- -------- ---------------- -------------- ----------
all-ones Unassigned UPSTREAM_LABEL [This.I-D] all-ones Unassigned UPSTREAM_LABEL [This.I-D]
Upstream Label Upstream Label
7. Security Considerations 5. 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
discussed by [RFC3473] still apply. discussed by [RFC3473] still apply.
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].
6. Acknowledgements
The authors would like to thank Adrian Farrel and Chris Bowers for
their inputs.
7. 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
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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://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.
 End of changes. 9 change blocks. 
43 lines changed or deleted 43 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/