GMPLS Synchronized Signaling for Optical Lightpath Setup
draft-martinelli-ccamp-synch-signaling-00.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 7, 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 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
2.  Information Required
3.  Bi-Directional Signalling Procedure
    3.1.  Synchronized Signaling Steps
    3.2.  Errors and Roll Back
    3.3.  Advantages and Disadvantages
4.  Backward Compatibility Considerations
5.  Error management
6.  Acknowledgments
7.  Contributing Authors
8.  IANA Considerations
9.  Security Considerations
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses

1.  Introduction

The Generalized Multi-Protocol Label Switching (GMPLS) extension related to Wavelength Switched Optical Networks (WSON) has to cope with the bidirectional LSP issue.

The [RFC3471] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description,” January 2003.) and [RFC3473] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions,” January 2003.) 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.draft-ietf-ccamp-rwa-wson-framework] context the bi-directionality might appear 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 to the deployed network even if it can be relaxed if the technology supports it.

In extending signaling to WSON requirements the following ID [I‑D.bernstein‑ccamp‑wson‑signaling] (Bernstein, G., “Signaling Extensions for Wavelength Switched Optical Networks,” February 2010.) explain a procedure regarding the signaling of a bidirectional LSP.

The currently 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:

• when path characteristics must be collected from source to destination (e.g. the optical signal parameters) as only the downstream direction can be evaluated
• when some (transit) nodes in the network do not support the extensions
• when the same wavelength selection is requested for the upstream and downstream directions and the distributed wavelength assignment is implemented

This memo is to define 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. The memo also review some advantages and disadvantages in term of 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] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions,” January 2003.), others might be identified as specific to WSON.

For the current purpose we identify the following information that need to be carried along the signaling phase:

• LSP bi-directionality. According to [RFC3471] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description,” January 2003.) the Upstream Label Object presence is a trigger for bi-directionality.
• Wavelength Bi-directionality. In some specific cases the network might require the same wavelength used in both directions.

3.  Bi-Directional Signalling 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 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.

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

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

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

• standard processing of RSVP messages (no additional operations performed in the RESV message processing)
• no need for ResvConf messages (each channel source point knows when the channel is setup by receiving the RESV message)
• 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)
• 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:

• Longer setup time due to double signaling. This issue however has to be evaluated in term of lightpath. They have slow setup time.
• 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:
  1. additional info in the RSVP PATH msg with associated LSP Id (and direction)
  2. associating the two LSP (upstream,downstream) to a CALL [RFC 4974] (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] (Bernstein, G., “Signaling Extensions for Wavelength Switched Optical Networks,” February 2010.)).

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):

   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

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 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” March 2008.) [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] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions,” January 2003.). GMPLS security is described in section 11 of [RFC3471] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description,” January 2003.).

10.  References

10.1. Normative References

10.2. Informative References

Authors' Addresses