Internet Engineering Task Force G. Martinelli, Ed. Internet-Draft Cisco Systems Intended status: Experimental A. Zanardi, Ed. Expires: January 13, 2010 CREATE-NET July 12, 2009 GMPLS Synchronized Signaling for Optical Lightpath Setup draft-martinelli-ccamp-synch-signaling-01.txt Status of this Memo This Internet-Draft is submitted to IETF 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 January 13, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract In Generalized Multi-Protocol Label Switching (GMPLS) several extension are proposed to cope with constrain provide Wavelength Martinelli & Zanardi Expires January 13, 2010 [Page 1] Internet-Draft GMPLS Synchronized Signaling July 2009 Switched Optical Networks (WSON). One of the technology constrain related to Dense Wavelength Division Multiplexing (DWDM) systems is the bi-directionality of the lightpath. This memo provides some consideration about how extending the signaling phase to cope with the bi-directional requirements. The procedure is independent from the wavelength continuity constrain in both direction. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Information Required . . . . . . . . . . . . . . . . . . . . . 3 3. Bi-Directional Signaling Procedure . . . . . . . . . . . . . . 4 3.1. Synchronized Signaling Steps . . . . . . . . . . . . . . . 4 3.2. Errors and Roll Back . . . . . . . . . . . . . . . . . . . 6 3.3. Advantages and Disadvantages . . . . . . . . . . . . . . . 6 4. Backward Compatibility Considerations . . . . . . . . . . . . 7 5. Error management . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Martinelli & Zanardi Expires January 13, 2010 [Page 2] Internet-Draft GMPLS Synchronized Signaling July 2009 1. Introduction The Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extension related to Wavelength Switched Optical Networks (WSON) has to cope with the bidirectional LSP issue. The [RFC3471] and [RFC3473] define the functional framework and encoding for bidirectional LSP setup. The presence of an Upstream Label Object (UL) during the signaling phase means that the LSP request is bidirectional and it also identifies the label to be used in the reverse direction. In the WSON [I-D.ietf-ccamp-rwa-wson-framework] context the bi- directionality appears as a strong requirement due to current available DWDM technology. The bidirectional LSP does not strictly require using the same wavelength in the two directions, however this could be a constrain in some deployed network while in other case this constrain can be relaxed (although keeping the bi- directionality). In extending signaling to WSON requirements the following ID [I-D.bernstein-ccamp-wson-signaling] explain a procedure regarding the signaling of a bidirectional LSP. The defined signaling extensions handle the setup of the upstream channel in the context of the downstream LSP session by adding additional objects to the request and requiring special node behaviors. This approach has some limitations in specific scenarios such as the case when path characteristics must be collected from source to destination (e.g. the optical signal parameters) as only the downstream direction can be evaluated. As an example considering a lightpath within an impairment aware control plane ([I-D.ietf-ccamp-wson-impairments]) even if the same wavelength is used for both directions the optical impairments for the two directions can be very different. This memo defines an operational procedure that exploits the bi- directionality with minimum requirements in term of protocol extensions and introducing a synchronization among the two signaling phases. [RFC3471] list a set of disadvantages of using two unidirectional path to implement a bi-directional LSP. The memo also review some of advantages and disadvantages with focus on optical lightpath. 2. Information Required To set up a bidirectional LSP in a WSON environment we need to identify the information required. Some information is already defined in standards like [RFC3473], others might be identified as Martinelli & Zanardi Expires January 13, 2010 [Page 3] Internet-Draft GMPLS Synchronized Signaling July 2009 specific to WSON. For the current purpose we identify the following information that need to be carried along the signaling phase: o LSP bi-directionality. According to [RFC3471] the Upstream Label Object presence is a trigger for bi-directionality. o Wavelength Bi-directionality. In some specific cases the network might require the same wavelength used in both directions. 3. Bi-Directional Signaling Procedure 3.1. Synchronized Signaling Steps The Bidirectional signaling is implemented through two independent signaling sessions (one for each direction) that are performed in synch keeping the upstream signaling nested in the downstream one. In this description we use the terms 'source' and 'destination' referring to the first request issued (downstream). For the upstream direction the destination is the node emitting the PATH and source the one emitting the RESV. 1. The source node signals a PATH request to the destination node for the downstream channel. 2. The destination node may apply any path validation procedure to asses the path feasibility. 3. The destination node signals a PATH request to the source node for the upstream channel with the path constrained by the ERO to use the same path as the downstream channel and, if requested, an initial LABEL_SET Object specifying the wavelengths available for the downstream LSPs (e.g. if the same wavelength is required for both direction). 4. The source node signals the RESV for the upstream channel to the destination node. The channel cross-connections are setup in the nodes. 5. The destination node signals the RESV for the downstream channel to the source node; if requested, the same wavelength selected by the upstream LSPs is signaled. The channel cross-connections are setup in the nodes. Martinelli & Zanardi Expires January 13, 2010 [Page 4] Internet-Draft GMPLS Synchronized Signaling July 2009 +------+ +------+ +------+ | LSR | | LSR | | LSR | | S | | i | | D | +------+ +------+ +------+ | | | | path-d | | |--------- | | | `---------->| | | | path-d | | |--------- | | | `---------->| | | | | | path-u | | | ___________| | | / | | path-u |<-------- | | ___________| | | / | | |<-------- | | | resv-u | | |--------- | | | `---------->| | | | resv-u | | |--------- | | | `---------->| | | ___________| | | / | | resv-d |<-------- | | ___________| | | / | | |<-------- | | | | | Message Sequence Chart for bidirectional synchronized LSP setup. Figure 1 The Figure 1 shows in a graphical format how the upstream signaling phase is nested within the downstream one, where: "LSR S" is the source node, "LSR i" is any intermediate node and "LSR D" is the destination node path-d represents the path signaling phase downstream that has to be bidirectional Martinelli & Zanardi Expires January 13, 2010 [Page 5] Internet-Draft GMPLS Synchronized Signaling July 2009 path-u represents the path signaling phase upstream resv-u represent the reservation phase for upstream resv-d represent the reservation phase for downstream 3.2. Errors and Roll Back In case of any error triggered the roll back procedure goes through a standard process apart from the processing at the destination node. 1. In case of error in the upstream LSP setup in the PATH or RESV signaling phase (PATHERR message received by the destination node), a PATHERR message is issued for the downstream node. 2. In case of error in the downstream RESV signaling phase, a PATHTEAR message is issued by the destination node for the upstream LSP 3.3. Advantages and Disadvantages The procedure has the following advantages o standard processing of RSVP-TE messages (no additional operations performed in the RESV message processing) o no need for ResvConf messages (each channel source point knows when the channel is setup by receiving the RESV message) o the symmetrical resource allocation constraint could be removed: a different wavelength can be used for the upstream channel (the wavelength can be discovered with the usual LABEL_SET object management) o in the MIBs (LSP MIB) both the upstream and downstream channel resources (labels, in-segment, out-segment) are explicitly reported We can identify the following disadvantages: o Longer setup time due to double signaling. This issue however has to be evaluated in term of lightpath. They have slow setup time. o The two LSPs are not explicitly associated in the network nodes; only the destination node keeps track of the relation. Two possible options can be foreseen: Martinelli & Zanardi Expires January 13, 2010 [Page 6] Internet-Draft GMPLS Synchronized Signaling July 2009 1. additional info in the RSVP PATH message with associated LSP Id (and direction) 2. associating the two LSP (upstream,downstream) to a CALL [RFC4974] (even if you then need to signal the CALL too...) 4. Backward Compatibility Considerations A full WSON signaling solution could not be compatible, in this case the possibility to reject bidirectional signaling shall be implemented (Example in [I-D.bernstein-ccamp-wson-signaling]). 5. Error management Specific Error management for the bidirectional case. 6. Acknowledgments 7. Contributing Authors This document was the collective work of several authors. The text and content of this document was contributed by the editors and the co-authors listed below (the contact information for the editors appears in appropriate section and is not repeated below): Martinelli & Zanardi Expires January 13, 2010 [Page 7] Internet-Draft GMPLS Synchronized Signaling July 2009 Gabriele Maria Galimberti Cisco Systems via Philips 12 Monza 20052 Italy Email: ggalimbe@cisco.com Alberto Tanzi Cisco Systems via Philips 12 Monza 20052 Italy Email: atanzi@cisco.com Domenico La Fauci Cisco Systems via Philips 12 Monza 20052 Italy Email: dlafauci@cisco.com Elio Salvadori CREATE-NET via alla Cascata 56 C, Povo Trento 38100 Italy Email: elio.salvadori@create-net.org Chava Vijaya Saradhi CREATE-NET via alla Cascata 56 C, Povo Trento 38100 Italy Email: saradhi.chava@create-net.org Martinelli & Zanardi Expires January 13, 2010 [Page 8] Internet-Draft GMPLS Synchronized Signaling July 2009 8. IANA Considerations This memo includes no request to IANA. All drafts are required to have an IANA considerations section (see the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor. 9. Security Considerations This document introduces no new security considerations to [RFC3473]. GMPLS security is described in section 11 of [RFC3471]. 10. References 10.1. Normative References [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 10.2. Informative References [I-D.bernstein-ccamp-wson-signaling] Bernstein, G., "Signaling Extensions for Wavelength Switched Optical Networks", draft-bernstein-ccamp-wson-signaling-04 (work in progress), July 2009. [I-D.ietf-ccamp-rwa-wson-framework] Bernstein, G., "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)", draft-ietf-ccamp-rwa-wson-framework-02 (work in progress), March 2009. [I-D.ietf-ccamp-wson-impairments] Bernstein, G., "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments", draft-ietf-ccamp-wson-impairments-00 (work in progress), Martinelli & Zanardi Expires January 13, 2010 [Page 9] Internet-Draft GMPLS Synchronized Signaling July 2009 June 2009. [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-09 (work in progress), March 2008. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007. Authors' Addresses Giovanni Martinelli (editor) Cisco Systems via Philips 12 Monza 20052 Italy Email: giomarti@cisco.com Andrea Zanardi (editor) CREATE-NET via alla Cascata 56 C, Povo Trento 38100 Italy Email: andrea.zanardi@create-net.org Martinelli & Zanardi Expires January 13, 2010 [Page 10]