CCAMP Working Group Vishnu Pavan Beeram (Ed) Internet Draft Juniper Networks Intended status: Standards Track Igor Bryskin (Ed) ADVA Optical Networking Expires: April 20, 2014 October 20, 2013 Network Assigned Upstream-Label draft-beeram-ccamp-network-assigned-upstream-label-00.txt 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 20, 2014. Copyright Notice Copyright (c) 2013 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 Beeram, et al Expires April 20, 2014 [Page 1] Internet-Draft Network Assigned Upstream Label July 2013 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document discusses the GMPLS RSVP-TE extensions that are needed to let the network assign an upstream-label for a given LSP. This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream-label on its own. This document also specifies the extensions required for manipulating Label-Symmetric Bidirectional GMPLS LSPs. 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. Label Symmetricity.............................................3 2.1. Processing Rules..........................................3 3. Unassigned Upstream Label......................................4 3.1. Processing Rules..........................................4 4. Upstream Label Set / Acceptable Upstream Label Set.............5 4.1. Object Formats............................................6 4.2. Processing Rules..........................................6 5. Use-Cases......................................................7 5.1. Alien-Wavelength Setup....................................7 5.1.1. Setup Procedure - Example............................8 6. Security Considerations.......................................10 7. IANA Considerations...........................................11 8. Normative References..........................................11 9. Acknowledgments...............................................11 1. Introduction The GMPLS RSVP-TE extensions for setting up a Bidirectional LSP are discussed 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. Beeram, et al Expires April 20, 2014 [Page 2] Internet-Draft Network Assigned Upstream Label July 2013 However, there are certain scenarios (Section 5) where it is not desirable for a given node to pick the upstream-label on its own. This document discusses the protocol extensions that are required in such cases to let the network assign an upstream-label for a given LSP. As per [RFC3471], the upstream-label and the downstream-label for an LSP at a given hop need not be the same. However, most practical scenarios require these two labels to be the same. This document proposes a mechanism for the ingress to request "Label Symmetricity" at each hop of the LSP. It also discusses how the request to have "Label Symmetricity" gets processed in conjunction with the request to have "a network assigned upstream-label". 2. Label Symmetricity In order to request "Label Symmetricity", this document defines a new flag (Label_Symmetricity Required) in the Attributes Flags TLV [RFC5420]. The position of this flag in the TLV is TBA. If the upstream-label and the downstream-label are required to be the same at each hop of the LSP, then the PATH sent out by the ingress would have this flag set in the Attributes Flags TLV of the LSP_REQUIRED_ATTRIBUTES object. 2.1. Processing Rules The presence of the "Label Symmetricity_Required" flag in the PATH message indicates that the LSP is bidirectional and that the labels are symmetric in both directions at each hop. Since this flag gets carried in the LSP_REQUIRED_ATTRIBUTES object, a downstream node that does not recognize/support this flag would reject the LSP setup request (indicating that the requested attributes are not supported). When this flag is set in the PATH message, the upstream node may or may not add the UPSTREAM_LABEL object in the initial setup request sent to the downstream node. If the UPSTREAM_LABEL does get specified in the PATH, the downstream nodes MUST ignore it. If the upstream node desires to pick the symmetric label on its own, it MUST encode this in the LABEL_SET object and send it downstream. The downstream-node picks an appropriate symmetric label and sends this via the LABEL object in the RESV message. The upstream-node would then start using this symmetric label for both directions of the LSP. Beeram, et al Expires April 20, 2014 [Page 3] Internet-Draft Network Assigned Upstream Label July 2013 +----------+ +------------+ ---| Upstream |--------------------| Downstream |--- +----------+ +------------+ PATH LSP Req Attr (Label Symmetricity) Label-Set (L) -------------------> RESV Label (Assigned - L) <------------------- PATH LSP Req Attr (Label Symmetricity) Upstream Label (Assigned - L) -------------------> Figure 1: Label Symmetricity The remaining extensions discussed in this document are not relevant for LSPs that require "Label Symmetricity". 3. Unassigned Upstream Label This document proposes the use of a special label value - "0xFFFFFFFF" - to indicate an Unassigned Label. This would get used by a node if it does not have any input on what upstream-label needs to get picked. This special label is filled in the UPSTREAM_LABEL object of the PATH message that is sent downstream. 3.1. Processing Rules In the ideal scenario, the network responds by filling in a valid UPSTREAM_LABEL in the corresponding RESV message. If the network is not in a position to assign the UPSTREAM LABEL (or if it doesn't know what to do with an Unassigned UPSTREAM_LABEL), it MUST issue a PATH- ERR message with a "Routing Problem/Unacceptable Label Value" indication. If the RESV comes in without an assigned UPSTREAM_LABEL, then an error with a "Routing Problem/Label Allocation Failure" indication MUST be issued. Beeram, et al Expires April 20, 2014 [Page 4] Internet-Draft Network Assigned Upstream Label July 2013 +----------+ +------------+ ---| Upstream |--------------------| Downstream |--- +----------+ +------------+ PATH Upstream Label (Unassigned) -------------------> RESV Upstream Label (Assigned - L1) Label (Assigned - L2) <------------------- PATH Upstream Label (Assigned - L1) -------------------> Figure 2: Unassigned UPSTREAM_LABEL The above processing rules do not apply if an "Unassigned UPSTREAM_LABEL" is included in a PATH message that also has the "Label_Symmetricity_Required" bit set. In that case, the downstream node would ignore the presence of the "UPSTREAM LABEL" (and the rules specified in Section 2.1 come into play). 4. Upstream Label Set / Acceptable Upstream Label Set This document proposes the use of UPSTREAM_LABEL_SET and ACCEPTABLE_UPSTREAM_LABEL_SET for scenarios where a given node desires to give the network some choices when picking a valid UPSTREAM_LABEL. The UPSTREAM_LABEL_SET object is the upstream equivalent of the LABEL_SET object. The UPSTREAM_LABEL_SET object carries a list of acceptable upstream labels and gets signaled in the PATH message that is sent downstream. The network responds by picking a valid UPSTREAM_LABEL from the given list and signals it back in the corresponding RESV message. The ACCEPTABLE_LABEL_SET is currently used to specify both upstream and downstream label-sets. However, in scenarios where there is no label symmetricity, it becomes necessary to have constructs that can specify both an acceptable upstream label-set and an acceptable downstream label-set at the same time. The ACCEPTABLE_UPSTREAM_LABEL_SET construct introduced in this document helps fill that void. Beeram, et al Expires April 20, 2014 [Page 5] Internet-Draft Network Assigned Upstream Label July 2013 4.1. Object Formats The UPSTREAM_LABEL_SET object uses Class-Number TBA (of form 0bbbbbbb) and the C-Type of 1. The format of UPSTREAM_LABEL_SET: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(TBA)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action | Reserved | Label Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchannel 1 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : | : : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchannel N | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The parameters are similar to ones defined for LABEL_SET. See [RFC3471] for their description. The ACCEPTABLE_UPSTREAM_LABEL_SET object uses class-number TBA (of form 10bbbbbb) and C-Type 1. The format/parameters of this object are identical to that of the UPSTREAM_LABEL_SET. 4.2. Processing Rules The inclusion of the optional UPSTREAM_LABEL_SET object in the PATH message indicates that the LSP is bidirectional. In the ideal case, the network picks a valid upstream-label from the specified list and fills this in the UPSTREAM_LABEL object of the corresponding RESV message. If the network is not able to pick a valid upstream-label from the list specified in the UPSTREAM_LABEL_SET, it MUST generate a PATH-ERR message with a "Routing Problem/Unacceptable Label value" indication. The PATH-ERR message may optionally include the ACCEPTABLE_UPSTREAM_LABEL_SET Beeram, et al Expires April 20, 2014 [Page 6] Internet-Draft Network Assigned Upstream Label July 2013 object to indicate a list of acceptable labels supported by the network at that instant. +----------+ +------------+ ---| Upstream |--------------------| Downstream |--- +----------+ +------------+ PATH Upstream Label Set (L1, L2 ... Ln) -------------------> RESV Upstream Label (Assigned - L2) Label (Assigned - Lx) <------------------- PATH Upstream Label (Assigned - L2) -------------------> Figure 3: UPSTREAM_LABEL_SET The UPSTREAM_LABEL object and the UPSTREAM_LABEL_SET object may both be included in a PATH message. The rules of processing when both objects are included are as follows: - If the UPSTREAM_LABEL carries a valid assigned value, then the UPSTREAM_LABEL_SET object (if present) MUST be ignored. - If the UPSTREAM LABEL carries an unassigned value, then the Unassigned UPSTREAM_LABEL MUST be ignored. The UPSTREAM_LABEL_SET gets processed instead in such cases. The above processing rules do not apply if an "USPTREAM_LABEL_SET" is included in a PATH message that also has the "Label_Symmetricity_Required" bit set. In that case, the downstream node would ignore the presence of the "UPSTREAM LABEL_SET" (and the rules specified in Section 2.1 come into play). 5. Use-Cases 5.1. Alien-Wavelength Setup Consider the network topology depicted in Figure 3. Nodes A and B are client IP routers that are connected to an optical WDM transport Beeram, et al Expires April 20, 2014 [Page 7] Internet-Draft Network Assigned Upstream Label July 2013 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. | | +---+ /-\ | | | Router ( ) WDM | +---+ Node \-/ node |________________________________ +---+ /-\ /-\ /-\ +---+ | A |---------( F )---------( H )---------( I )---------| B | +---+ \-/ \-/ \-/ +---+ Figure 4: Sample topology 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 via an optical-filter. 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 correct wavelength. In particular, for some tunable filter implementations, multiplexing of signals with the same wavelength will result in an unreadable signal on that wavelength. Hence, having the router send signal with 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. The mechanisms proposed in this document allow the optical network specify the correct wavelength for such clients. 5.1.1. Setup Procedure - Example The following is an illustration of gracefully setting up ([GR- SETUP]) a Lambda LSP using "Unassigned Upstream Label". "Label Symmetricity" is not requested for the LSP in this particular example. Beeram, et al Expires April 20, 2014 [Page 8] Internet-Draft Network Assigned Upstream Label July 2013 +---+ /-\ /-\ +---+ | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | +---+ \-/ \-/ +---+ Step 1: PATH Admin Status (A, R) Upstream Label (Unassigned) ---------------------> -- ~~ -- ~~ --> PATH Admin Status (A, R) --------------------> RESV Admin Status (A) <-------------------- <-- ~~ -- ~~ -- RESV Admin Status (A) Upstream Label (Assigned) <--------------------- Step 2: PATH Admin Status (R), Upstream Label (Assigned) ---------------------> -- ~~ -- ~~ --> PATH Admin Status (R) --------------------> RESV Admin Status <-------------------- <-- ~~ -- ~~ -- RESV Admin Status Upstream Label (Assigned) <-------------------- Figure 5: Alien Wavelength Setup Beeram, et al Expires April 20, 2014 [Page 9] Internet-Draft Network Assigned Upstream Label July 2013 Step 1: - "Router A" does not have enough information to pick the correct client wavelength. It sends a PATH downstream requesting the network to assign an appropriate UPSTREAM_LABEL for it to use. As per the graceful setup procedure outlined in [GR-SETUP], the PATH is sent out with the "A" bit set in the ADMIN_STATUS. This indicates that the LSP is not operational and that the laser is turned off at the ingress client. - The network receives the PATH, chooses the correct wavelength values and forwards them in appropriate label fields to the egress client ("Router B") - "Router B" receives the PATH, turns the laser ON and tunes it to the correct wavelength (received in the LABEL_SET of the PATH) and sends out a RESV upstream. The RESV is sent out with the "A" bit set in the ADMIN_STATUS - indicating that the LSP is still not operational. - The RESV received by the ingress client carries a valid assigned UPSTREAM label. "Router A" turns on the laser and tunes it to the wavelength specified in the network assigned UPSTREAM_LABEL. This completes Step-1. Step 2: - "Router A" sends out a PATH trigger with the "A" bit cleared in the ADMIN_STATUS. This indicates the ingress client's desire to make the LSP operational - The network receives the PATH, adjusts the power-levels appropriately (also takes care of any other applicable provisioning operations) and then forwards the PATH with the "A" bit cleared to the egress client. - The egress client sends out a RESV trigger in response with the "A" bit cleared in the ADMIN_STATUS. From this point on, the LSP is deemed "ready for use" by the egress client. - The RESV with the "A" bit cleared in the ADMIN_STATUS makes its way to the ingress client. From this point on, the LSP is deemed fully operational by the ingress client. 6. Security Considerations TBD Beeram, et al Expires April 20, 2014 [Page 10] Internet-Draft Network Assigned Upstream Label July 2013 7. IANA Considerations TBD 8. 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. [RFC5420] Farrel, A., "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC5420, February 2009. [UP-LBL-SET] Oki, E., "Upstream Label Set Support in RSVP-TE extensions", , June 2002. [GR-SETUP] Beeram, V., "RSVP Graceful Setup", , October 2013 9. Acknowledgments We would like to acknowledge the authors of for introducing the notion of an UPSTREAM_LABEL_SET. Authors' Addresses Vishnu Pavan Beeram Juniper Networks Email: vbeeram@juniper.net John Drake Juniper Networks Email: jdrake@juniper.net Gert Grammel Beeram, et al Expires April 20, 2014 [Page 11] Internet-Draft Network Assigned Upstream Label July 2013 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 Beeram, et al Expires April 20, 2014 [Page 12]