GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8359

Internet Engineering Task Force (IETF) X. Zhang, Ed. Request for Comments: 8359 Huawei Technologies Updates: 3471, 3473, 6205 V. Beeram, Ed. Category: Standards Track Juniper Networks ISSN: 2070-1721 I. Bryskin

                                                   Huawei Technologies
                                                         D. Ceccarelli
                                                              Ericsson
                                                   O. Gonzalez de Dios
                                                            Telefonica
                                                            March 2018
                  Network-Assigned Upstream Label

Abstract

 This document discusses a Generalized Multi-Protocol Label Switching
 (GMPLS) Resource reSerVation Protocol with Traffic Engineering
 (RSVP-TE) mechanism that enables the network to assign an upstream
 label for a bidirectional Label Switched Path (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.  This document
 updates RFCs 3471, 3473, and 6205 as it defines processing for a
 special label value in the UPSTREAM_LABEL object.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 https://www.rfc-editor.org/info/rfc8359.

Zhang, et al. Standards Track [Page 1] RFC 8359 Network Assigned Upstream-Label March 2018

Copyright Notice

 Copyright (c) 2018 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (https://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
 2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
 3.  Unassigned Upstream Label . . . . . . . . . . . . . . . . . .   3
   3.1.  Procedures  . . . . . . . . . . . . . . . . . . . . . . .   4
   3.2.  Backwards Compatibility . . . . . . . . . . . . . . . . .   5
 4.  Use-Case: Wavelength Setup for IP over Optical Networks . . .   5
   4.1.  Initial Setup . . . . . . . . . . . . . . . . . . . . . .   6
   4.2.  Wavelength Change . . . . . . . . . . . . . . . . . . . .   7
 5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
 6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
 7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
   7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
 Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction

 A functional description of the Generalized Multi-Protocol Label
 Switching (GMPLS) signaling extensions for setting up a bidirectional
 Label Switched Path (LSP) is provided in [RFC3471].  The GMPLS
 Resource reSerVation Protocol with Traffic Engineering (RSVP-TE)
 extensions for setting up a bidirectional LSP are specified in
 [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 (see Section 4) where it is not desirable or
 possible for a given node to pick the upstream label on its own.

Zhang, et al. Standards Track [Page 2] RFC 8359 Network Assigned Upstream-Label March 2018

 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 to
 nodes downstream in the network.  It is meant to be used only for
 bidirectional LSPs that assign symmetric labels at each hop along the
 path of the LSP.  Bidirectional Lambda Switch Capable (LSC) LSPs use
 symmetric lambda labels (format specified in [RFC6205]) at each hop
 along the path of the LSP.
 As per the bidirectional LSP setup procedures specified in [RFC3471]
 and [RFC3473], the UPSTREAM_LABEL object must indicate a label that
 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 UPSTREAM_LABEL object to carry a special label value
 that is different from the one used in the LABEL_SET object.

2. 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.

3. Unassigned Upstream Label

 This document defines a special label value -- "0xFFFFFFFF" (for a
 4-octet label) -- to indicate an Unassigned Upstream Label.  Similar
 "all-ones" patterns are expected to be used for labels of other
 sizes.
     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|
    |                              ...                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Figure 1: Unassigned UPSTREAM_LABEL - "all-ones" Pattern
 The presence of this value in the 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.

Zhang, et al. Standards Track [Page 3] RFC 8359 Network Assigned Upstream-Label March 2018

 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.

3.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
 selection, it MUST specify a list of valid labels via the LABEL_SET
 object as specified in [RFC3473].
 In response, the downstream node picks an appropriate symmetric label
 and sends it via the LABEL object in the Resv message.  The upstream
 node would then start using this symmetric label for both directions
 of the LSP.  If the downstream node cannot pick the symmetric label,
 it MUST issue a PathErr message with a "Routing Problem/Unacceptable
 Label Value" indication.  If the upstream node that signals an
 Unassigned Upstream Label receives a label with the "all-ones"
 pattern or any other unacceptable label in the LABEL object of the
 Resv message, it MUST issue a ResvErr message with a "Routing
 Problem/Unacceptable Label Value" indication.
 The upstream node will continue to signal the Unassigned Upstream
 Label in the Path message even after it receives an appropriate
 symmetric label in the Resv message.  This is done to make sure that
 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
 node receives an unacceptable changed label, then it MUST issue a
 ResvErr message with a "Routing Problem/Unacceptable Label Value"
 indication.

Zhang, et al. Standards Track [Page 4] RFC 8359 Network Assigned Upstream-Label March 2018

                +----------+                    +------------+
             ---| Upstream |--------------------| Downstream |---
                +----------+                    +------------+
                            Path
                             Upstream Label (Unassigned)
                             Label-Set (L1, L2 ... Ln)
                            ------------------->
                            Resv
                             Label (Assigned - L2)
                            <-------------------
                     Figure 2: Signaling Sequence

3.2. Backwards Compatibility

 If the downstream node is running an implementation that doesn't
 support 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 no backwards
 compatibility concerns.  If the behavior that is exhibited is (b),
 then the downstream node will send a label with the "all-ones"
 pattern in the LABEL object of the Resv message.  In response, the
 upstream node will issue a ResvErr message with a "Routing Problem/
 Unacceptable Label Value" indication.

4. Use-Case: Wavelength Setup for IP over Optical Networks

 Consider the network topology depicted in Figure 3.  Nodes A and B
 are client IP routers that are connected to an optical Wavelength
 Division Multiplexing (WDM) transport network.  F and I represent WDM
 nodes.  The transponder sits on the router and is directly connected
 to the add-drop port on a WDM node.
 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 the signal into the optical network unless it is at the
 appropriate wavelength.  In other words, having the router send
 signals 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 in
 advance.

Zhang, et al. Standards Track [Page 5] RFC 8359 Network Assigned Upstream-Label March 2018

 The rest of this section examines how the protocol mechanism proposed
 in this document allows the optical network to select and communicate
 the correct wavelength to its clients.

4.1. Initial Setup

       +---+                 /-\             /-\                 +---+
       | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B |
       +---+                 \-/             \-/                 +---+
          Path
            Upstream Label (Unassigned/0xFFFFFFFF)
          --------------------->
                                -- ~~ -- ~~ -->
                                                Path
                                                -------------------->
                                                Resv
                                                <--------------------
                                <-- ~~ -- ~~ --
          Resv
            Label (Assigned)
          <---------------------
                   Figure 3: Initial Setup Sequence
 Steps:
 o  "Router A" does not have enough information to pick an 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 unknown, the laser is off at the
    ingress client.
 o  The downstream node (Node F) receives the Path message, chooses
    the appropriate wavelength values, and forwards them in
    appropriate label fields to the egress client ("Router B").
 o  "Router B" receives the Path message, turns the laser ON and tunes
    it to the appropriate wavelength (received in the UPSTREAM_LABEL/
    LABEL_SET of the Path) and sends a Resv message upstream.
 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.

Zhang, et al. Standards Track [Page 6] RFC 8359 Network Assigned Upstream-Label March 2018

 For cases where the egress-node relies on RSVP signaling to determine
 exactly when to start using the LSP, implementations may choose to
 integrate the above sequence with any of the existing graceful setup
 procedures:
 o  "ResvConf" setup procedure ([RFC2205])
 o  Two-step "ADMIN STATUS" based setup procedure ("A" bit set in the
    first step; "A" bit cleared when the LSP is ready for use)
    ([RFC3473])

4.2. Wavelength Change

 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
 including policy reasons, restoration within the core, preemption,
 etc.
 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
 at the ingress to the new wavelength.  Similarly, if the egress
 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
 wavelength.

5. IANA Considerations

 IANA maintains the "Generalized Multi-Protocol Label Switching
 (GMPLS) Signaling Parameters" registry.  IANA has added a new
 subregistry titled "Special Purpose Generalized Label Values".  New
 values are assigned according to Standards Action [RFC8126].
 Special Purpose Generalized Label Values
 Pattern/    Label Name            Applicable        Reference
 Value                             Objects
 --------    ----------------      --------------    ----------
 all-ones    Unassigned            UPSTREAM_LABEL    [RFC8359]
             Upstream Label

6. Security Considerations

 This document defines a special label value to be carried in the
 UPSTREAM_LABEL object of a Path message.  This special label value is
 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

Zhang, et al. Standards Track [Page 7] RFC 8359 Network Assigned Upstream-Label March 2018

 corresponding procedures.  Thus, there are no new security
 implications raised by this document and the security considerations
 discussed by [RFC3473] still apply.
 For a general discussion on MPLS and GMPLS related security issues,
 see the MPLS/GMPLS security framework [RFC5920].

7. References

7.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <https://www.rfc-editor.org/info/rfc2119>.
 [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
            Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
            Functional Specification", RFC 2205, DOI 10.17487/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
            Switching (GMPLS) Signaling Resource ReserVation Protocol-
            Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
            DOI 10.17487/RFC3473, January 2003,
            <https://www.rfc-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>.

Zhang, et al. Standards Track [Page 8] RFC 8359 Network Assigned Upstream-Label March 2018

7.2. Informative References

 [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
            Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
            <https://www.rfc-editor.org/info/rfc5920>.
 [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
            Writing an IANA Considerations Section in RFCs", BCP 26,
            RFC 8126, DOI 10.17487/RFC8126, June 2017,
            <https://www.rfc-editor.org/info/rfc8126>.

Acknowledgements

 The authors would like to thank Adrian Farrel and Chris Bowers for
 their inputs.

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

Zhang, et al. Standards Track [Page 9] RFC 8359 Network Assigned Upstream-Label March 2018

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

Zhang, et al. Standards Track [Page 10]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8359.txt · Last modified: 2018/03/13 22:36 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki