One document matched: 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 7, 2010 CREATE-NET
July 06, 2009
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
Martinelli & Zanardi Expires January 7, 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 . . . . . . . . . . . . . . . . . . . . . 4
3. Bi-Directional Signalling 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 7, 2010 [Page 2]
Internet-Draft GMPLS Synchronized Signaling July 2009
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] 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.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] 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:
o when path characteristics must be collected from source to
destination (e.g. the optical signal parameters) as only the
downstream direction can be evaluated
o when some (transit) nodes in the network do not support the
extensions
o 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.
Martinelli & Zanardi Expires January 7, 2010 [Page 3]
Internet-Draft GMPLS Synchronized Signaling July 2009
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
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 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
Martinelli & Zanardi Expires January 7, 2010 [Page 4]
Internet-Draft GMPLS Synchronized Signaling July 2009
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.
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
Martinelli & Zanardi Expires January 7, 2010 [Page 5]
Internet-Draft GMPLS Synchronized Signaling July 2009
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
o standard processing of RSVP 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
Martinelli & Zanardi Expires January 7, 2010 [Page 6]
Internet-Draft GMPLS Synchronized Signaling July 2009
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]).
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 7, 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 7, 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.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009.
10.2. Informative References
[I-D.bernstein-ccamp-wson-signaling]
Bernstein, G., "Signaling Extensions for Wavelength
Switched Optical Networks",
draft-bernstein-ccamp-wson-signaling-03 (work in
progress), October 2008.
[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.
Martinelli & Zanardi Expires January 7, 2010 [Page 9]
Internet-Draft GMPLS Synchronized Signaling July 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.
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 7, 2010 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 05:00:19 |