One document matched: draft-martinelli-ccamp-synch-signaling-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2205 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2205.xml">
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC3945 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3945.xml">
<!ENTITY RFC3471 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3471.xml">
<!ENTITY RFC3473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3473.xml">
<!ENTITY RFC4054 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4054.xml">
<!ENTITY RFC5420 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5420.xml">
<!ENTITY RFC4328 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4328.xml">
<!ENTITY RFC4974 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4974.xml">
<!ENTITY I-D.ietf-ccamp-rwa-wson-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-rwa-wson-framework-02">
<!ENTITY I-D.ietf-ccamp-wson-impairments SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-wson-impairments-00">
<!ENTITY I-D.bernstein-ccamp-wson-signaling
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bernstein-ccamp-wson-signaling.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="exp" docName="draft-martinelli-ccamp-synch-signaling-01.txt" ipr="trust200811">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="GMPLS Synchronized Signaling ">
GMPLS
Synchronized Signaling for Optical Lightpath Setup
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Giovanni Martinelli" initials="G. M." role="editor" surname="Martinelli">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>via Philips 12</street>
<code>20052</code>
<city>Monza</city>
<country>Italy</country>
</postal>
<email>giomarti@cisco.com</email>
</address>
</author>
<author fullname="Andrea Zanardi" initials="A. Z." role="editor" surname="Zanardi">
<organization>CREATE-NET</organization>
<address>
<postal>
<street>via alla Cascata 56 C, Povo</street>
<code>38100</code>
<city>Trento</city>
<country>Italy</country>
</postal>
<email>andrea.zanardi@create-net.org</email>
</address>
</author>
<date day="12" month="July" year="2009" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>kw1</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<!-- ######################################################## -->
<section title="Introduction">
<t>
The Generalized Multi-Protocol Label Switching (GMPLS)
<xref target="RFC3945"/> extension
related to Wavelength Switched Optical Networks (WSON) has to cope
with the bidirectional LSP issue.
</t>
<t>
The <xref target="RFC3471"/> and <xref target="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.
</t>
<t>
In the WSON <xref target="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).
</t>
<t>
In extending signaling to WSON requirements the following ID
<xref target="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
(<xref target="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.
</t>
<t>
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. <xref target="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.
</t>
</section> <!-- Introduction-->
<!-- ######################################################## -->
<section title="Information Required" anchor="sec_info_req">
<t>
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 <xref target="RFC3473"/>,
others might be identified as specific to WSON.
</t>
<t>
For the current purpose we identify the following information that
need to be carried along the signaling phase:
<list style='symbols'>
<t>
LSP bi-directionality. According to <xref target="RFC3471"/> the
Upstream Label Object presence is a trigger for bi-directionality.
</t>
<t>
Wavelength Bi-directionality. In some specific cases the network
might require the same wavelength used in both directions.
</t>
<!--
<t>
Upstream Label Set Object (as it was in
draft-oki-ccamp-upstream-labelset-00.txt?).
<cref anchor="Q1_1" source="AZ">
The upstream label set is the solution to the upstream
label selection in distributed WA (when the same wl is
not required).
It somehow makes useless the bi-directional signaling...
</cref>
</t>
-->
</list>
</t>
</section> <!-- Information Required -->
<!-- ######################################################## -->
<section title="Bi-Directional Signaling Procedure">
<section title="Synchronized Signaling Steps">
<t>
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.
</t>
<t>
<list style="numbers">
<t>
The source node signals a PATH request to the destination
node for the downstream channel.
</t>
<t>
The destination node may apply any path validation procedure to
asses the path feasibility.
</t>
<t>
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).
</t>
<t>
The source node signals the RESV for the upstream channel
to the destination node. The channel cross-connections
are setup in the nodes.
</t>
<t>
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.
<cref anchor="Q1_2" source="AZ">
Better describing the error management after
the main flow.
Should we add a picture for the rollback on error?
</cref>
</t>
</list>
</t>
<figure align="center" anchor="fig_sycnh_sig">
<artwork align="left"><![CDATA[
+------+ +------+ +------+
| LSR | | LSR | | LSR |
| S | | i | | D |
+------+ +------+ +------+
| | |
| path-d | |
|--------- | |
| `---------->| |
| | path-d |
| |--------- |
| | `---------->|
| | |
| | path-u |
| | ___________|
| | / |
| path-u |<-------- |
| ___________| |
| / | |
|<-------- | |
| resv-u | |
|--------- | |
| `---------->| |
| | resv-u |
| |--------- |
| | `---------->|
| | ___________|
| | / |
| resv-d |<-------- |
| ___________| |
| / | |
|<-------- | |
| | |
]]></artwork>
<postamble>Message Sequence Chart for bidirectional synchronized
LSP setup.
</postamble>
</figure>
<t>
The <xref target="fig_sycnh_sig"/> shows in a graphical format
how the upstream signaling phase is nested within the downstream
one, where:
<list style="empty">
<t>"LSR S" is the source node, "LSR i" is any intermediate node
and "LSR D" is the destination node</t>
<t>path-d represents the path signaling phase downstream that
has to be bidirectional</t>
<t>path-u represents the path signaling phase upstream</t>
<t>resv-u represent the reservation phase for upstream</t>
<t>resv-d represent the reservation phase for downstream</t>
</list>
</t>
</section>
<section title="Errors and Roll Back">
<t>
In case of any error triggered the roll back procedure
goes through a standard process apart from the processing
at the destination node.
<cref anchor="Q1_3" source="AZ">
Error mgmt already described above in the signaling flow.
May be we should keep only one description
</cref>
</t>
<!-- AZ: better later
<t>
The source node might emit
a PATH Error to the destination
node which, in turn, sends a PATH Error for the downstream
channel.
</t>
-->
<t>
<list style="numbers">
<t>
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.
</t>
<t>
In case of error in the downstream RESV signaling phase,
a PATHTEAR message is issued by the destination node
for the upstream LSP
</t>
</list>
</t>
</section>
<section title="Advantages and Disadvantages">
<t>
The procedure has the following advantages
<list style="symbols">
<t>
standard processing of RSVP-TE messages
(no additional operations performed in the RESV message
processing)
</t>
<t>
no need for ResvConf messages (each channel source
point knows when the channel is setup by receiving the
RESV message)
</t>
<t>
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)
</t>
<t>
in the MIBs (LSP MIB) both the upstream and downstream
channel resources (labels, in-segment, out-segment) are
explicitly reported
</t>
</list>
</t>
<t>
We can identify the following disadvantages:
<list style="symbols">
<t>
Longer setup time due to double signaling. This issue
however has to be evaluated in term of lightpath. They
have slow setup time.
</t>
<t>
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:
<list style="numbers">
<t>
additional info in the RSVP PATH message
with associated LSP Id (and direction)
</t>
<t>
associating the two LSP (upstream,downstream)
to a CALL <xref target="RFC4974"/>
(even if you then need to signal the CALL too...)
</t>
</list>
</t>
</list>
</t>
</section>
</section> <!-- Bi-Directional Signalling Procedure -->
<!-- ######################################################## -->
<section title="Backward Compatibility Considerations">
<!--
<t>
The solution could be implemented using the current standard
signaling encoding.
<cref anchor="Q1_5" source="AZ">
But at least the flags for the bi-dir request should
be added (e.g. identifying if it's a downstream or
upstreaam requrest)
Bits in LSP_REQUIRED_ATTRIBUTES?
</cref>
</t>
-->
<t>
A full WSON signaling solution could not be compatible,
in this case the possibility to reject bidirectional
signaling shall be implemented (Example in
<xref target="I-D.bernstein-ccamp-wson-signaling"/>).
</t>
</section> <!-- Backward Compatibility Considerations -->
<!-- ##################### END OF SECTION ########################### -->
<section anchor="error_management" title="Error management">
<t>
Specific Error management for the bidirectional case.
</t>
<!--
<t>
No additional error code is introduced to manage requests
failures; the behavior defined in <xref target="RFC4420"/>
applies to the management of the LSP_REQUIRED_ATTRIBUTES
Object.
<cref anchor="Q1_6" source="AZ">
Where LSP_REQUIRED_ATTRIBUTES are used?
WARN: the RFC for REQUIRED_ATTRIBUTES is now 5420 (NOT 4420)
</cref>
</t>
-->
</section>
<!-- ############################## -->
<section anchor="Acknowledgments" title="Acknowledgments">
<t>
</t>
</section>
<!-- ############################## -->
<section anchor="Contributors" title="Contributing Authors">
<t> 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):
</t>
<figure align="left">
<artwork align="left"><![CDATA[
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
]]></artwork>
</figure>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
<t>All drafts are required to have an IANA considerations section (see
<xref target="I-D.narten-iana-considerations-rfc2434bis">the update of
RFC 2434</xref> 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.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
This document introduces no new security considerations to
<xref target="RFC3473"/>.
GMPLS security is described in section 11 of
<xref target="RFC3471"/>.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC3471;
&RFC3473;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC3945;
&RFC4974;
&I-D.ietf-ccamp-rwa-wson-framework;
&I-D.ietf-ccamp-wson-impairments;
&I-D.bernstein-ccamp-wson-signaling;
&I-D.narten-iana-considerations-rfc2434bis;
<!-- A reference written by by an organization not a person. -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:13:10 |