TEAS Working Group                             Vishnu Pavan Beeram                                      Xian Zhang (Ed)
 Internet Draft                                         Juniper Networks                                      Huawei Technologies
 Intended status: Standards Track               Vishnu Pavan Beeram (Ed)
                                                        Juniper Networks

 Expires: April 19, January 07, 2017                                 July 07, 2016                                October 19, 2015

                       Network Assigned Upstream-Label
             draft-ietf-teas-network-assigned-upstream-label-02
             draft-ietf-teas-network-assigned-upstream-label-03

 Status of this Memo

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    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
    months 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."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html

    This Internet-Draft will expire on April 19, 2016. January 07, 2017.

 Copyright Notice

    Copyright (c) 2015 2016 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
    (http://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.

 Abstract

    This document discusses a GMPLS (Generalized Generalized Multi-Protocol Label
    Switching) RSVP-TE (Resource Switching
    (GMPLS) Resource reSerVation Protocol with Traffic
    Engineering) protocol 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.

 Conventions used in this document

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC-2119 [RFC2119].

 Table of Contents

    1. Introduction...................................................2
    2. Use-Case: Alien Wavelength Setup...............................3 Setup for IP over Optical Networks........3
    3. The "Crank-Back" Approach......................................3 "Crankback Signaling" Approach.............................4
    4. Symmetric Labels...............................................5
    5. Unassigned Upstream Label......................................5
       5.1. Processing Rules..........................................5 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............................................8 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

    The GMPLS (Generalized Generalized Multi-Protocol Label Switching) RSVP-TE
    (Resource Switching (GMPLS) Resource
    reSerVation Protocol with Traffic Engineering) Engineering (RSVP-TE) extensions
    for setting up a bidirectional LSP are discussed 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 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: Alien Wavelength Setup for IP over Optical Networks

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

                               |
                               | +---+            /-\
                               | |   | Router    (   ) WDM
                               | +---+ Node       \-/  node
                               |________________________________

      +---+          /-\           /-\           /-\          +---+
      | A |---------( F )---------( H )---------( I )---------| B |
      +---+          \-/           \-/           \-/          +---+

                     Figure 1: Sample Topology

 3. The "Crank-Back" "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.

    The following setup sequence is an attempt "Crankback Signaling" [RFC4920] approach can be applied to
    address the above use-
    case using use-case as shown in the crank-back approach supported by GMPLS RSVP-TE: following setup sequence:

      +---+                 /-\             /-\                 +---+
      | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B |
      +---+                 \-/             \-/                 +---+

         PATH
           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

    The above approach does work, but there are a few obvious concerns:

    - Since "Router-A" does not know which upstream label to use, it
      picks some random label and signals it without programming its
      data-plane (this is a deviation from the UPSTREAM_LABEL processing
      procedures outlined in [RFC3473]).  As a result, the outgoing PATH
      message has no indication of whether the upstream label has been
      installed along the data-path or not.
    - If Even if "Router-A" somehow correctly guesses (by sheer luck) an acceptable
      upstream label upfront, the network may end up finding a path
      which is suboptimal (there could be a different acceptable
      upstream label which corresponds to a better path in the network)
    - The "PATH-ERR with Acceptable Label Set" retry approach is usually
      used for exception handling.  The above solution uses it for
      almost every single setup request (except in the rare scenario
      where the appropriate upstream label is guessed correctly).
    - There is an awkward window between the time the network sends out
      the PATH-ERR message (with the ACCEPTABLE_LABEL_SET) and receives
      the corresponding PATH message (with the selected UPSTREAM_LABEL);
      this window opens up the possibility of the selected
      UPSTREAM_LABEL to be stale by the time the network receives the
      retry PATH.
    - The above solution assumes the use of "symmetric labels" by
      default.

    The rest of the sections in this draft present a solution proposal
    that is devoid of any of the above concerns.

 4. Symmetric Labels

    As per [RFC3471], the upstream label and the downstream label for an
    LSP at a given hop need not be the same.  The use-case discussed in
    this document pertains to Lambda Switch Capable (LSC) LSPs and it is
    an undocumented fact that in practice, LSC LSPs always have
    symmetric labels at each hop along the path of the LSP.

    The use of the protocol mechanism discussed in this document
    mandates "Label Symmetry".  This mechanism is meant to be used only
    for bidirectional LSPs that assign symmetric labels at each hop
    along the path of the LSP.

 5. Unassigned Upstream Label

    This document proposes the use of a special label value -
    "0xFFFFFFFF" (for a 4-byte label) - to indicate an Unassigned
    Upstream Label.  Similar "all-ones" patterns are expected to be used
    for labels of other sizes.  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
    forward and reverse directions.  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.

 5.1. Processing Rules

    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 PATH-ERR 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 point in time.

               +----------+                    +------------+
            ---| Upstream |--------------------| Downstream |---
               +----------+                    +------------+

                           PATH
                            Upstream Label (Unassigned)
                            Label-Set (L1, L2 ... Ln)
                           ------------------->

                           RESV
                            Label (Assigned - L2)
                           <-------------------

                     Figure 3: Unassigned UPSTREAM_LABEL

 5.2. Backwards Compatibility

    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 [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
    0xFFFFFFFF 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

    The use-case discussed in Section 2 is revisited to examine how the
    mechanism proposed in this document allows the optical network to
    select and communicate the correct wavelength to its clients.

 6.1. Initial Setup

      +---+                 /-\             /-\                 +---+
      | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B |
      +---+                 \-/             \-/                 +---+

         PATH
           Upstream Label (Unassigned/0xFFFFFFFF)
         --------------------->
                               -- ~~ -- ~~ -->
                                               PATH
                                               -------------------->
                                               RESV
                                               <--------------------
                               <-- ~~ -- ~~ --
         RESV
           Label (Assigned)
         <---------------------

                      Figure 4: Alien Wavelength - Initial Setup Sequence

    Steps:
      - "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.
       - 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")
       - "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 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
    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

    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 - 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 RESV modify, it MUST retune the laser at
    the ingress to the new wavelength. Similarly  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 [RFC3473] MUST be followed.

 7. 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
    corresponding procedures.  Thus, there are no new security
    implications raised by this document. document and the security considerations
    put together by [RFC3473] still applies.

    For a general discussion on MPLS and GMPLS related security issues,
    see the MPLS/GMPLS security framework [RFC5920].
 8. IANA Considerations

    This document makes no requests for IANA action.

 9. References

 9.1. Normative References

    [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

    [RFC3471]    Berger, L., "Generalized Multi-Protocol Label Switching
                 Signaling Functional Description", RFC 3471, January
                 2003

    [RFC3473]    Berger, L., "Generalized Multi-Protocol Label Switching
                 Signaling Resource Reservation Protocol-Traffic
                 Engineering Extensions", RFC 3473, January 2003.

    [RFC4920]    Farrel, A., "Crankback Signaling Extensions for MPLS
                 and GMPLS RSVP-TE", RFC 4920, July 2007.

 9.2. Informative References

    [RFC5920]    Fang, L., "Security Framework for MPLS and GMPLS
                 Networks", RFC 5920, July 2010.

 10. Acknowledgments

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

 Authors' Addresses

    Xian Zhang
    Huawei Technologies
    Email: zhang.xian@huawei.com
    Vishnu Pavan Beeram
    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

 Contributors

    John Drake
    Juniper Networks
    Email: jdrake@juniper.net

    Gert Grammel
    Juniper Networks
    Email: ggrammel@juniper.net

    Igor Bryskin
    ADVA Optical Networking
    Email: ibryskin@advaoptical.com

    Pawel Brzozowski
    ADVA Optical Networking
    Email: pbrzozowski@advaoptical.com

    Daniele Ceccarelli
    Ericsson
    Email: daniele.ceccarelli@ericsson.com

    Oscar Gonzalez de Dios
    Telefonica
    Email: ogondio@tid.es

    Zafar Ali
    Cisco Systems, Inc.
    Email: zali@cisco.com

    Xian Zhang
    Huawei Technologies
    Email: zhang.xian@huawei.com