draft-ietf-teas-network-assigned-upstream-label-07.txt   draft-ietf-teas-network-assigned-upstream-label-08.txt 
skipping to change at page 1, line 16 skipping to change at page 1, line 16
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: February 12, 2018 I. Bryskin Expires: February 12, 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 August 11, 2017
Network Assigned Upstream-Label Network Assigned Upstream-Label
draft-ietf-teas-network-assigned-upstream-label-07 draft-ietf-teas-network-assigned-upstream-label-08
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. RFC3473.
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.
skipping to change at page 2, line 43 skipping to change at page 2, line 43
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The Generalized Multi-Protocol Label Switching (GMPLS) Resource The Generalized Multi-Protocol Label Switching (GMPLS) Resource
reSerVation Protocol with Traffic Engineering (RSVP-TE) extensions reSerVation Protocol with Traffic Engineering (RSVP-TE) extensions
for setting up a bidirectional LSP are specified in [RFC3473]. The for setting up a bidirectional Label Switched Path (LSP) are
bidirectional LSP setup is indicated by the presence of an specified in [RFC3473]. The bidirectional LSP setup is indicated by
UPSTREAM_LABEL Object in the PATH message. As per the existing setup the presence of an UPSTREAM_LABEL Object in the PATH message. As per
procedure outlined for a bidirectional LSP, each upstream node must the existing setup procedure outlined for a bidirectional LSP, each
allocate a valid upstream label on the outgoing interface before upstream node must allocate a valid upstream label on the outgoing
sending the initial PATH message downstream. However, there are interface before sending the initial PATH message downstream.
certain scenarios where it is not desirable or possible for a given However, there are certain scenarios 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. This bidirectional LSPs that assign symmetric labels at each hop along the
document updates [RFC3473] as it defines processing for a special path of the LSP. This document updates [RFC3473] as it defines
label value. processing for a special label value.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Unassigned Upstream Label 2. Unassigned Upstream Label
This document proposes the use of a special label value - This document proposes the use of a special label value -
skipping to change at page 4, line 44 skipping to change at page 4, line 44
backwards compatibility concerns. If there is some existing backwards compatibility concerns. If there is some existing
implementation that exhibits the behavior in (b), then there could be implementation that exhibits the behavior in (b), then there could be
some potential issues. However, at the time of publication, there is some potential issues. However, at the time of publication, there is
no documented evidence of any existing implementation that uses the no documented evidence of any existing implementation that uses the
"all-ones" bit pattern as a valid label. Thus, it is safe to assume "all-ones" bit pattern as a valid label. Thus, it is safe to assume
that the behavior in (b) will never be exhibited. 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 2. 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
appropriate wavelength. In other words, having the router send appropriate wavelength. In other words, having the router send
signals with a wrong wavelength may adversely impact existing optical signals with a wrong wavelength may adversely impact existing optical
skipping to change at page 6, line 33 skipping to change at page 6, line 33
o "RESV-CONF" setup procedure ([RFC2205]) o "RESV-CONF" 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
 End of changes. 5 change blocks. 
20 lines changed or deleted 20 lines changed or added

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