One document matched: draft-martinelli-ccamp-synch-signaling-01.txt
Differences from draft-martinelli-ccamp-synch-signaling-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 04:59:15 |