draft-ietf-teas-network-assigned-upstream-label-09.txt   draft-ietf-teas-network-assigned-upstream-label-10.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: May 3, 2018 I. Bryskin Expires: June 18, 2018 I. Bryskin
Huawei Technologies Huawei Technologies
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
O. Gonzalez de Dios O. Gonzalez de Dios
Telefonica Telefonica
October 30, 2017 December 15, 2017
Network Assigned Upstream-Label Network Assigned Upstream-Label
draft-ietf-teas-network-assigned-upstream-label-09 draft-ietf-teas-network-assigned-upstream-label-10
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 May 3, 2018. This Internet-Draft will expire on June 18, 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 50 skipping to change at page 2, line 50
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 where it is not desirable or possible for a given
node to pick the upstream label on its own. This document defines node to pick the upstream label on its own. This document defines
the protocol mechanism to be used in such scenarios. This mechanism the protocol mechanism to be used in such scenarios. This mechanism
enables a given node to offload the task of assigning the upstream enables a given node to offload the task of assigning the upstream
label for a given bidirectional LSP to nodes downstream in the label for a given bidirectional LSP to nodes downstream in the
network. It is meant to be used only for bidirectional LSPs that network. It is meant to be used only for bidirectional LSPs that
assign symmetric labels at each hop along the path of the LSP. assign symmetric labels at each hop along the path of the LSP.
Bidirectional Lambda Switch Capable (LSC) LSPs use symmetric lambda Bidirectional Lambda Switch Capable (LSC) LSPs use symmetric lambda
labels (format specified in [RFC6205]) at each hop along the path of labels (format specified in [RFC6205]) at each hop along the path of
the LSP. the LSP.
skipping to change at page 3, line 43 skipping to change at page 3, line 43
0 1 2 3 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 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| |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 Figure 1: Unassigned UPSTREAM_LABEL - "all-ones" Pattern
The presence of this value in the UPSTREAM_LABEL object of a PATH The presence of this value in the UPSTREAM_LABEL object of a Path
message indicates that the upstream node has not assigned an upstream 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 on its own and has requested the downstream node to provide a
label that it can use in both the forward and reverse directions. 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 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 message MUST also be interpreted by the receiving node as a request
to mandate symmetric labels for the LSP. to mandate symmetric labels for the LSP.
2.1. Procedures 2.1. Procedures
The scope of the procedures is limited to the exchange and processing The scope of the procedures is limited to the exchange and processing
of messages between an upstream node and its immediate downstream of messages between an upstream node and its immediate downstream
node. The Unassigned Upstream Label is used by an upstream node when 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 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 such a scenario, the upstream node sends a Path message downstream
with an Unassigned Upstream Label and requests the downstream node to with an Unassigned Upstream Label and requests the downstream node to
provide a symmetric label. If the upstream node desires to make the 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 PathErr message with a "Routing Problem/Unacceptable
Label Value" indication. If the upstream node that signals an Label Value" indication. If the upstream node that signals an
Unassigned Upstream Label receives a label with the "all-ones" Unassigned Upstream Label receives a label with the "all-ones"
pattern in the LABEL object of the RESV message, it MUST issue a pattern in the LABEL object of the Resv message, it MUST issue a
RESV-ERR message with a "Routing Problem/Unacceptable Label" ResvErr message with a "Routing Problem/Unacceptable Label"
indication. 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 it MUST issue a node receives an unacceptable changed label, then it MUST issue a
RESV-ERR message with a "Routing Problem/Unacceptable Label" ResvErr message with a "Routing Problem/Unacceptable Label"
indication. 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)
<------------------- <-------------------
Figure 2: Signaling Sequence Figure 2: Signaling Sequence
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 no backwards If the behavior that is exhibited is (a), then there are no backwards
compatibility concerns. If the behavior that is exhibited is (b), compatibility concerns. If the behavior that is exhibited is (b),
then the downstream node will send a label with the "all-ones" then the downstream node will send a label with the "all-ones"
pattern in the LABEL object of the RESV message. In response, the pattern in the LABEL object of the Resv message. In response, the
upstream node will issue a RESV-ERR message with a "Routing Problem/ upstream node will issue a ResvErr message with a "Routing Problem/
Unassigned Label" indication. Unassigned Label" indication.
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 3. 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.
skipping to change at page 6, line 8 skipping to change at page 6, line 8
The rest of this section examines how the protocol mechanism proposed The rest of this section examines how the protocol mechanism proposed
in this document allows the optical network to select and communicate in this document allows the optical network to select and communicate
the correct wavelength to its clients. the correct wavelength to its clients.
3.1. Initial Setup 3.1. Initial Setup
+---+ /-\ /-\ +---+ +---+ /-\ /-\ +---+
| A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B |
+---+ \-/ \-/ +---+ +---+ \-/ \-/ +---+
PATH Path
Upstream Label (Unassigned/0xFFFFFFFF) Upstream Label (Unassigned/0xFFFFFFFF)
---------------------> --------------------->
-- ~~ -- ~~ --> -- ~~ -- ~~ -->
PATH Path
--------------------> -------------------->
RESV Resv
<-------------------- <--------------------
<-- ~~ -- ~~ -- <-- ~~ -- ~~ --
RESV Resv
Label (Assigned) Label (Assigned)
<--------------------- <---------------------
Figure 3: Initial Setup Sequence Figure 3: Initial Setup Sequence
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
the appropriate wavelength values and forwards them in appropriate the appropriate wavelength values and forwards them in appropriate
label fields to the egress client ("Router B"). label fields to the egress client ("Router B").
o "Router B" receives the PATH message, turns the laser ON and tunes o "Router B" receives the Path message, turns the laser ON and tunes
it to the appropriate wavelength (received in the UPSTREAM_LABEL/ it to the appropriate wavelength (received in the UPSTREAM_LABEL/
LABEL_SET of the PATH) and sends a RESV message upstream. LABEL_SET of the Path) and sends a Resv message upstream.
o The RESV message received by the ingress client carries a valid o The Resv message received by the ingress client carries a valid
symmetric label in the LABEL object. "Router A" turns on the symmetric label in the LABEL object. "Router A" turns on the
laser and tunes it to the wavelength specified in the network laser and tunes it to the wavelength specified in the network
assigned symmetric LABEL. assigned symmetric LABEL.
For cases where the egress-node relies on RSVP signaling to determine For cases where the egress-node relies on RSVP signaling to determine
exactly when to start using the LSP, implementations may choose to exactly when to start using the LSP, implementations may choose to
integrate the above sequence with any of the existing graceful setup integrate the above sequence with any of the existing graceful setup
procedures: procedures:
o "RESV-CONF" setup procedure ([RFC2205]) o "ResvConf" setup procedure ([RFC2205])
o 2-step "ADMIN STATUS" based setup procedure ("A" bit set in the o 2-step "ADMIN STATUS" based setup procedure ("A" bit set in the
first step; "A" bit cleared when the LSP is ready for use). first step; "A" bit cleared when the LSP is ready for use).
([RFC3473]) ([RFC3473])
3.2. Wavelength Change 3.2. Wavelength Change
After the LSP is set up, the network may decide to change the 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 wavelength for the given LSP. This could be for a variety of reasons
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. Acknowledgements
The authors would like to thank Adrian Farrel and Chris Bowers for The authors would like to thank Adrian Farrel and Chris Bowers for
their inputs. their inputs.
5. Contributors 5. Contributors
John Drake John Drake
skipping to change at page 8, line 16 skipping to change at page 8, line 16
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 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
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].
 End of changes. 30 change blocks. 
33 lines changed or deleted 33 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/