draft-ietf-teas-network-assigned-upstream-label-03.txt   draft-ietf-teas-network-assigned-upstream-label-04.txt 
TEAS Working Group Xian Zhang (Ed) TEAS Working Group X. Zhang, Ed.
Internet Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track Vishnu Pavan Beeram (Ed) Intended status: Standards Track V. Beeram, Ed.
Juniper Networks Expires: September 12, 2017 Juniper Networks
I. Bryskin
Expires: January 07, 2017 July 07, 2016 Huawei Technologies
D. Ceccarelli
Ericsson
O. Gonzalez de Dios
Telefonica
March 11, 2017
Network Assigned Upstream-Label Network Assigned Upstream-Label
draft-ietf-teas-network-assigned-upstream-label-03 draft-ietf-teas-network-assigned-upstream-label-04
Status of this Memo Abstract
This Internet-Draft is submitted in full conformance with the This document discusses a Generalized Multi-Protocol Label Switching
provisions of BCP 78 and BCP 79. (GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP-
TE) mechanism that enables the network to assign an upstream label
for a bidirectional 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.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six This Internet-Draft is submitted in full conformance with the
months and may be updated, replaced, or obsoleted by other documents provisions of BCP 78 and BCP 79.
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Internet-Drafts are working documents of the Internet Engineering
http://www.ietf.org/ietf/1id-abstracts.txt Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
The list of Internet-Draft Shadow Directories can be accessed at Internet-Drafts are draft documents valid for a maximum of six months
http://www.ietf.org/shadow.html and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 07, 2017. This Internet-Draft will expire on September 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Table of Contents
This document discusses a Generalized Multi-Protocol Label Switching 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
(GMPLS) Resource reSerVation Protocol with Traffic Engineering 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
(RSVP-TE) mechanism that enables the network to assign an upstream 2. Use-Case: Wavelength Setup for IP over Optical Networks . . . 3
label for a bidirectional LSP. This is useful in scenarios where a 3. The "Crankback Signaling" Approach . . . . . . . . . . . . . 3
given node does not have sufficient information to assign the 4. Symmetric Labels . . . . . . . . . . . . . . . . . . . . . . 5
correct upstream label on its own and needs to rely on the 5. Unassigned Upstream Label . . . . . . . . . . . . . . . . . . 5
downstream node to pick an appropriate label. 5.1. Processing Rules . . . . . . . . . . . . . . . . . . . . 6
5.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 6
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Initial Setup . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Wavelength Change . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
Conventions used in this document 1. Introduction
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The Generalized Multi-Protocol Label Switching (GMPLS) Resource
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this reSerVation Protocol with Traffic Engineering (RSVP-TE) extensions
document are to be interpreted as described in RFC-2119 [RFC2119]. for setting up a bidirectional LSP are specified in RFC 3473
[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 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 onto the network.
Table of Contents 1.1. Requirements Language
1. Introduction...................................................2 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
2. Use-Case: Wavelength Setup for IP over Optical Networks........3 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
3. The "Crankback Signaling" Approach.............................4 document are to be interpreted as described in RFC 2119 [RFC2119].
4. Symmetric Labels...............................................5
5. Unassigned Upstream Label......................................5
5.1. Processing Rules..........................................6
5.2. Backwards Compatibility...................................6
6. Applicability..................................................7
6.1. Initial Setup.............................................7
6.2. Wavelength Change.........................................8
7. Security Considerations........................................8
8. IANA Considerations............................................9
9. References.....................................................9
9.1. Normative References......................................9
9.2. Informative References....................................9
10. Acknowledgments...............................................9
Authors' Addresses................................................9
Contributors.....................................................10
1. Introduction 2. Use-Case: Wavelength Setup for IP over Optical Networks
The Generalized Multi-Protocol Label Switching (GMPLS) Resource Consider the network topology depicted in Figure 1. Nodes A and B
reSerVation Protocol with Traffic Engineering (RSVP-TE) extensions are client IP routers that are connected to an optical WDM transport
for setting up a bidirectional LSP are specified in [RFC3473]. The network. F, H and I represent WDM nodes. The transponder sits on
bidirectional LSP setup is indicated by the presence of an the router and is directly connected to the add-drop port on a WDM
UPSTREAM_LABEL Object in the PATH message. As per the existing node.
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 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 onto the network.
2. Use-Case: Wavelength Setup for IP over Optical Networks 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 signal into the optical network unless it is at the
appropriate wavelength. In other words, having the router send
signal 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
up-front.
Consider the network topology depicted in Figure 1. Nodes A and B |
are client IP routers that are connected to an optical WDM transport | +---+ /-\
network. F, H and I represent WDM nodes. The transponder sits on | | | Router ( ) WDM
the router and is directly connected to the add-drop port on a WDM | +---+ Node \-/ node
node. |________________________________
The optical signal originating on "Router A" is tuned to a +---+ /-\ /-\ /-\ +---+
particular wavelength. On "WDM-Node F", it gets multiplexed with | A |---------( F )---------( H )---------( I )---------| B |
optical signals at other wavelengths. Depending on the +---+ \-/ \-/ \-/ +---+
implementation of this multiplexing function, it may not be
acceptable to have the router send signal into the optical network
unless it is at the appropriate wavelength. In other words, having
the router send signal 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 up-front.
| Sample Topology
| +---+ /-\
| | | Router ( ) WDM
| +---+ Node \-/ node
|________________________________
+---+ /-\ /-\ /-\ +---+ Figure 1
| A |---------( F )---------( H )---------( I )---------| B |
+---+ \-/ \-/ \-/ +---+
Figure 1: Sample Topology 3. The "Crankback Signaling" Approach
3. The "Crankback Signaling" Approach There are currently no GMPLS RSVP-TE protocol mechanisms that an
upstream node can use for indicating that it does not know what
upstream label to use and that it needs the downstream node to pick
the label on its behalf.
There are currently no GMPLS RSVP-TE protocol mechanisms that an The "Crankback Signaling" RFC 4920 [RFC4920] approach can be applied
upstream node can use for indicating that it does not know what to address the above use-case as shown in the following setup
upstream label to use and that it needs the downstream node to pick sequence:
the label on its behalf.
The "Crankback Signaling" [RFC4920] approach can be applied to +---+ /-\ /-\ +---+
address the above use-case as shown in the following setup sequence: | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B |
+---+ \-/ \-/ +---+
+---+ /-\ /-\ +---+ PATH
| A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | Upstream Label (any available value)
+---+ \-/ \-/ +---+ --------------------->
PATH-ERR
Routing problem/Unacceptable Label Value
Acceptable Label Set (L1, L2 .. Ln)
<---------------------
PATH
Upstream Label (L2)
--------------------->
-- ~~ -- ~~ -->
PATH
-------------------->
RESV
<--------------------
<-- ~~ -- ~~ --
RESV
Label (Assigned)
<---------------------
PATH Setup Sequence - Crank-back Approach
Upstream Label (any available value)
--------------------->
PATH-ERR
Routing problem/Unacceptable Label Value
Acceptable Label Set (L1, L2 .. Ln)
<---------------------
PATH
Upstream Label (L2)
--------------------->
-- ~~ -- ~~ -->
PATH
-------------------->
RESV
<--------------------
<-- ~~ -- ~~ --
RESV
Label (Assigned)
<---------------------
Figure 2: Setup Sequence - Crank-back Approach Figure 2
The above approach does work, but there are a few obvious concerns: The above approach does work, but there are a few obvious concerns:
- Since "Router-A" does not know which upstream label to use, it o Since "Router-A" does not know which upstream label to use, it
picks some random label and signals it without programming its picks some random label and signals it without programming its
data-plane (this is a deviation from the UPSTREAM_LABEL processing data-plane (this is a deviation from the UPSTREAM_LABEL processing
procedures outlined in [RFC3473]). As a result, the outgoing PATH procedures outlined in RFC 3473 [RFC3473]). As a result, the
message has no indication of whether the upstream label has been outgoing PATH message has no indication of whether the upstream
installed along the data-path or not. label has been installed along the data-path or not.
- Even if "Router-A" somehow correctly guesses an acceptable
o Even if "Router-A" somehow correctly guesses an acceptable
upstream label upfront, the network may end up finding a path upstream label upfront, the network may end up finding a path
which is suboptimal (there could be a different acceptable which is suboptimal (there could be a different acceptable
upstream label which corresponds to a better path in the network) upstream label which corresponds to a better path in the network)
- The "PATH-ERR with Acceptable Label Set" retry approach is usually
o The "PATH-ERR with Acceptable Label Set" retry approach is usually
used for exception handling. The above solution uses it for used for exception handling. The above solution uses it for
almost every single setup request (except in the rare scenario almost every single setup request (except in the rare scenario
where the appropriate upstream label is guessed correctly). where the appropriate upstream label is guessed correctly).
- There is an awkward window between the time the network sends out
o There is an awkward window between the time the network sends out
the PATH-ERR message (with the ACCEPTABLE_LABEL_SET) and receives the PATH-ERR message (with the ACCEPTABLE_LABEL_SET) and receives
the corresponding PATH message (with the selected UPSTREAM_LABEL); the corresponding PATH message (with the selected UPSTREAM_LABEL);
this window opens up the possibility of the selected this window opens up the possibility of the selected
UPSTREAM_LABEL to be stale by the time the network receives the UPSTREAM_LABEL to be stale by the time the network receives the
retry PATH. retry PATH.
- The above solution assumes the use of "symmetric labels" by
o The above solution assumes the use of "symmetric labels" by
default. default.
The rest of the sections in this draft present a solution proposal The rest of the sections in this draft present a solution proposal
that is devoid of any of the above concerns. that is devoid of any of the above concerns.
4. Symmetric Labels 4. Symmetric Labels
As per [RFC3471], the upstream label and the downstream label for an As per RFC 3471 [RFC3471], the upstream label and the downstream
LSP at a given hop need not be the same. The use-case discussed in label for an LSP at a given hop need not be the same. The use-case
this document pertains to Lambda Switch Capable (LSC) LSPs and it is discussed in this document pertains to Lambda Switch Capable (LSC)
an undocumented fact that in practice, LSC LSPs always have LSPs and it is an undocumented fact that in practice, LSC LSPs always
symmetric labels at each hop along the path of the LSP. have symmetric labels at each hop along the path of the LSP.
The use of the protocol mechanism discussed in this document The use of the protocol mechanism discussed in this document mandates
mandates "Label Symmetry". This mechanism is meant to be used only "Label Symmetry". This mechanism is meant to be used only for
for bidirectional LSPs that assign symmetric labels at each hop bidirectional LSPs that assign symmetric labels at each hop along the
along the path of the LSP. path of the LSP.
5. Unassigned Upstream Label 5. Unassigned Upstream Label
This document proposes the use of a special label value - This document proposes the use of a special label value -
"0xFFFFFFFF" (for a 4-byte label) - to indicate an Unassigned "0xFFFFFFFF" (for a 4-byte label) - to indicate an Unassigned
Upstream Label. Similar "all-ones" patterns are expected to be used Upstream Label. Similar "all-ones" patterns are expected to be used
for labels of other sizes. The presence of this value in the for labels of other sizes. The presence of this value in the
UPSTREAM_LABEL object of a PATH message indicates that the upstream UPSTREAM_LABEL object of a PATH message indicates that the upstream
node has not assigned an upstream label on its own and has requested 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 downstream node to provide a label that it can use in both
forward and reverse directions. The presence of this value in the forward and reverse directions. The presence of this value in the
UPSTREAM_LABEL object of a PATH message MUST also be interpreted by UPSTREAM_LABEL object of a PATH message MUST also be interpreted by
the receiving node as a request to mandate "symmetric labels" for the receiving node as a request to mandate "symmetric labels" for the
the LSP. LSP.
5.1. Processing Rules 5.1. Processing Rules
The Unassigned Upstream Label is used by an upstream node when it is 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 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 scenario, the upstream node sends a PATH message downstream with an
Unassigned Upstream Label and requests the downstream node to Unassigned Upstream Label and requests the downstream node to provide
provide a symmetric label. If the upstream node desires to make the 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 RFC 3473 [RFC3473].
In response, the downstream node picks an appropriate symmetric In response, the downstream node picks an appropriate symmetric label
label and sends it via the LABEL object in the RESV message. The and sends it via the LABEL object in the RESV message. The upstream
upstream node would then start using this symmetric label for both node would then start using this symmetric label for both directions
directions of the LSP. If the downstream node cannot pick the of the LSP. If the downstream node cannot pick the symmetric label,
symmetric label, it MUST issue a PATH-ERR message with a "Routing it MUST issue a PATH-ERR message with a "Routing Problem/Unacceptable
Problem/Unacceptable Label Value" indication. Label Value" 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 point in time. when it needs to change the label at a later point in time.
+----------+ +------------+ +----------+ +------------+
---| 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 3: Unassigned UPSTREAM_LABEL Unassigned UPSTREAM_LABEL
5.2. Backwards Compatibility Figure 3
If the downstream node is running an older implementation and 5.2. Backwards Compatibility
doesn't understand 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 obviously
no backwards compatibility concerns. If there is some existing
implementation that exhibits the behavior in (b), then there could
be some potential issues. However, at the time of publication,
there is no documented evidence of any existing implementation that
uses the "all-ones" bit pattern as a valid label. Thus, it is safe
to assume that the behavior in (b) will never be exhibited.
6. Applicability If the downstream node is running an older implementation and doesn't
understand 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 RFC 3473 [RFC3473] or (b) accept it and
treat it as a valid label.
The use-case discussed in Section 2 is revisited to examine how the If the behavior that is exhibited is (a), then there are obviously no
mechanism proposed in this document allows the optical network to backwards compatibility concerns. If there is some existing
select and communicate the correct wavelength to its clients. implementation that exhibits the behavior in (b), then there could be
some potential issues. However, at the time of publication, there is
no documented evidence of any existing implementation that uses the
"all-ones" bit pattern as a valid label. Thus, it is safe to assume
that the behavior in (b) will never be exhibited.
6.1. Initial Setup 6. Applicability
+---+ /-\ /-\ +---+ The use-case discussed in Section 2 is revisited to examine how the
| A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | mechanism proposed in this document allows the optical network to
+---+ \-/ \-/ +---+ select and communicate the correct wavelength to its clients.
PATH 6.1. Initial Setup
Upstream Label (Unassigned/0xFFFFFFFF)
--------------------->
-- ~~ -- ~~ -->
PATH
-------------------->
RESV
<--------------------
<-- ~~ -- ~~ --
RESV
Label (Assigned)
<---------------------
Figure 4: Initial Setup Sequence +---+ /-\ /-\ +---+
| A |----------------( F ) ~~~~~~~~~ ( I )----------------| B |
+---+ \-/ \-/ +---+
Steps: PATH
- "Router A" does not have enough information to pick an Upstream Label (Unassigned/0xFFFFFFFF)
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 PATH
unknown, the laser is off at the ingress client. -------------------->
- The downstream node (Node F) receives the PATH message, chooses RESV
the appropriate wavelength values and forwards them in <--------------------
appropriate label fields to the egress client ("Router B") <-- ~~ -- ~~ --
- "Router B" receives the PATH message, turns the laser ON and RESV
tunes it to the appropriate wavelength (received in the Label (Assigned)
UPSTREAM_LABEL/LABEL_SET of the PATH) and sends out a RESV <---------------------
message upstream.
- 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 Initial Setup Sequence
determine exactly when to start using the LSP, this draft recommends
integrating the above sequence with any of the existing graceful
setup procedures:
- "RESV-CONF" setup procedure (or)
- 2-step "ADMIN STATUS" based setup procedure ("A" bit set in the
first step; "A" bit cleared when the LSP is ready for use).
6.2. Wavelength Change Figure 4
After the LSP is set up, the network MAY decide to change the Steps:
wavelength for the given LSP. This could be for a variety of
reasons - policy reasons, restoration within the core, preemption
etc.
In such a scenario, if the ingress client receives a changed label o "Router A" does not have enough information to pick an appropriate
via the LABEL object in a RESV modify, it MUST retune the laser at client wavelength. It sends a PATH message downstream requesting
the ingress to the new wavelength. Similarly, if the egress client the network to assign an appropriate symmetric label for its use.
receives a changed label via UPSTREAM_LABEL/LABEL_SET in a PATH
modify, it MUST retune the laser at the egress to the new
wavelength. If the node receiving the changed label in a PATH/RESV
message does not find the label acceptable, then the corresponding
error procedures defined in [RFC3473] MUST be followed.
7. Security Considerations Since the client wavelength is unknown, the laser is off at the
ingress client.
This document defines a special label value to be carried in the o The downstream node (Node F) receives the PATH message, chooses
UPSTREAM_LABEL object of a PATH message. This special label value the appropriate wavelength values and forwards them in appropriate
is used to enable the function of requesting network assignment of label fields to the egress client ("Router B")
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
put together by [RFC3473] still applies.
For a general discussion on MPLS and GMPLS related security issues, o "Router B" receives the PATH message, turns the laser ON and tunes
see the MPLS/GMPLS security framework [RFC5920]. it to the appropriate wavelength (received in the UPSTREAM_LABEL/
8. IANA Considerations LABEL_SET of the PATH) and sends out a RESV message upstream.
This document makes no requests for IANA action. 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.
9. References For cases where the egress-node relies on RSVP signaling to determine
exactly when to start using the LSP, this draft recommends
integrating the above sequence with any of the existing graceful
setup procedures:
9.1. Normative References o "RESV-CONF" setup procedure (or)
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate o 2-step "ADMIN STATUS" based setup procedure ("A" bit set in the
Requirement Levels", BCP 14, RFC 2119, March 1997. first step; "A" bit cleared when the LSP is ready for use).
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 6.2. Wavelength Change
Signaling Functional Description", RFC 3471, January
2003
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching After the LSP is set up, the network MAY decide to change the
Signaling Resource Reservation Protocol-Traffic wavelength for the given LSP. This could be for a variety of reasons
Engineering Extensions", RFC 3473, January 2003. - policy reasons, restoration within the core, preemption etc.
[RFC4920] Farrel, A., "Crankback Signaling Extensions for MPLS In such a scenario, if the ingress client receives a changed label
and GMPLS RSVP-TE", RFC 4920, July 2007. via the LABEL object in a RESV modify, it MUST retune 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 PATH
modify, it MUST retune the laser at the egress to the new wavelength.
If the node receiving the changed label in a PATH/RESV message does
not find the label acceptable, then the corresponding error
procedures defined in RFC 3473 [RFC3473] MUST be followed.
9.2. Informative References 7. Acknowledgements
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS The authors would like to thank Adrian Farrel and Chris Bowers for
Networks", RFC 5920, July 2010. their inputs.
10. Acknowledgments 8. Contributors
The authors would like to thank Adrian Farrel and Chris Bowers for John Drake
their inputs. Juniper Networks
Email: jdrake@juniper.net
Authors' Addresses Gert Grammel
Juniper Networks
Email: ggrammel@juniper.net
Xian Zhang Pawel Brzozowski
Huawei Technologies ADVA Optical Networking
Email: zhang.xian@huawei.com Email: pbrzozowski@advaoptical.com
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net
Igor Bryskin Zafar Ali
Huawei Technologies Cisco Systems, Inc.
Email: igor.bryskin@huawei.com Email: zali@cisco.com
Daniele Ceccarelli 9. IANA Considerations
Ericsson
Email: daniele.ceccarelli@ericsson.com
Oscar Gonzalez de Dios This document makes no requests for IANA action.
Telefonica
Email: ogondio@tid.es
Contributors 10. Security Considerations
John Drake This document defines a special label value to be carried in the
Juniper Networks UPSTREAM_LABEL object of a PATH message. This special label value is
Email: jdrake@juniper.net 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
put together by RFC 3473 [RFC3473] still applies.
Gert Grammel For a general discussion on MPLS and GMPLS related security issues,
Juniper Networks see the MPLS/GMPLS security framework RFC 5920 [RFC5920].
Email: ggrammel@juniper.net
Pawel Brzozowski 11. References
ADVA Optical Networking
Email: pbrzozowski@advaoptical.com
Zafar Ali 11.1. Normative References
Cisco Systems, Inc.
Email: zali@cisco.com [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, DOI 10.17487/RFC3471, January 2003,
<http://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,
<http://www.rfc-editor.org/info/rfc3473>.
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N.,
and G. Ash, "Crankback Signaling Extensions for MPLS and
GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007,
<http://www.rfc-editor.org/info/rfc4920>.
11.2. Informative References
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>.
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
 End of changes. 89 change blocks. 
328 lines changed or deleted 310 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/