One document matched: draft-bernstein-ccamp-wson-signaling-05.txt
Differences from draft-bernstein-ccamp-wson-signaling-04.txt
Network Working Group G. Bernstein
Internet Draft Grotto Networking
Intended status: Standards Track Sugang Xu
NICT
Expires: April 2010 Y.Lee
Huawei
Hiroaki Harai
NICT
D. King
October 22, 2009
Signaling Extensions for Wavelength Switched Optical Networks
draft-bernstein-ccamp-wson-signaling-05.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 April 22, 2009.
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.
Expires April 22, 2010 [Page 1]
Internet-Draft WSON Signaling Extensions October 2009
Abstract
This memo provides extensions to Generalized Multi-Protocol Label
Switching (GMPLS) signaling for control of wavelength switched optical
networks (WSON). Such extensions are necessary in WSONs under a number
of conditions including: (a) when optional processing, such as
regeneration, must be indicated to occur at specific nodes along a path,
(b) where equipment must be configured to accept an optical signal with
specific attributes, or (c) where equipment must be configured to output
an optical signal with specific attributes. In addition this memo
provides mechanisms to support distributed wavelength assignment in
bidirectional LSP, and choice in distributed wavelength assignment
algorithms. These extensions build on previous work for the control of
lambda and G.709 based networks.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................3
3. Requirements for WSON Signaling................................4
3.1. WSON Signal Characterization..............................4
3.2. Per LSP Network Element Processing Configuration..........5
3.3. Bi-Directional Distributed Wavelength Assignment..........5
3.4. Distributed Wavelength Assignment Support.................6
3.5. Out of Scope..............................................7
4. WSON Signal Traffic Parameters, Attributes and Processing......7
4.1. Traffic Parameters for Optical Tributary Signals..........7
4.2. Signal Attributes and Processing..........................7
4.2.1. Modulation Type sub-TLV..............................8
4.2.2. FEC Type sub-TLV....................................10
4.2.3. Regeneration Processing TLV.........................12
5. Bidirectional Lightpath using Same Wavelength.................12
5.1. Using LSP_ATTRIBUTES Object..............................13
5.2. Bidirectional Lightpath Signaling Procedure..............13
5.3. Backward Compatibility Considerations....................14
6. Bidirectional Lightpath using Different Wavelengths...........15
7. RWA Related...................................................15
7.1. Wavelength Assignment Method Selection...................15
8. Security Considerations.......................................15
9. IANA Considerations...........................................16
Bernstein et al. Expires April 22, 2010 [Page 2]
Internet-Draft WSON Signaling Extensions October 2009
10. Acknowledgments..............................................16
11. References...................................................17
11.1. Normative References....................................17
11.2. Informative References..................................17
Author's Addresses...............................................19
Intellectual Property Statement..................................20
Disclaimer of Validity...........................................20
1. Introduction
This memo provides extensions to Generalized Multi-Protocol Label
Switching (GMPLS) signaling for control of wavelength switched
optical networks (WSON). Fundamental extensions are given to permit
simultaneous bi-directional wavelength assignment. While more
advanced extensions are given to support the networks described in
[WSON-Comp] which feature connections requiring configuration of
input, output, and general signal processing capabilities at a node
along a LSP
These extensions build on previous work for the control of lambda and
G.709 based networks.
2. Terminology
CWDM: Coarse Wavelength Division Multiplexing.
DWDM: Dense Wavelength Division Multiplexing.
FOADM: Fixed Optical Add/Drop Multiplexer.
ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port
count wavelength selective switching element featuring ingress and
egress line side ports as well as add/drop side ports.
RWA: Routing and Wavelength Assignment.
Wavelength Conversion/Converters: The process of converting an
information bearing optical signal centered at a given wavelength to
one with "equivalent" content centered at a different wavelength.
Wavelength conversion can be implemented via an optical-electronic-
optical (OEO) process or via a strictly optical process.
WDM: Wavelength Division Multiplexing.
Wavelength Switched Optical Networks (WSON): WDM based optical
networks in which switching is performed selectively based on the
center wavelength of an optical signal.
Bernstein et al. Expires April 22, 2010 [Page 3]
Internet-Draft WSON Signaling Extensions October 2009
AWG: Arrayed Waveguide Grating.
OXC: Optical Cross Connect.
Optical Transmitter: A device that has both a laser tuned on certain
wavelength and electronic components, which converts electronic
signals into optical signals.
Optical Responder: A device that has both optical and electronic
components. It detects optical signals and converts optical signals
into electronic signals.
Optical Transponder: A device that has both an optical transmitter
and an optical responder.
Optical End Node: The end of a wavelength (optical lambdas) lightpath
in the data plane. It may be equipped with some optical/electronic
devices such as wavelength multiplexers/demultiplexer (e.g. AWG),
optical transponder, etc., which are employed to transmit/terminate
the optical signals for data transmission.
3. Requirements for WSON Signaling
The following requirements for GMPLS based WSON signaling are in
addition to the functionality already provided by existing GMPLS
signaling mechanisms.
3.1. WSON Signal Characterization
WSON signaling MUST convey sufficient information characterizing the
signal to allow systems along the path to determine compatibility and
perform any required local configuration. Examples of such systems
include intermediate nodes (ROADMs, OXCs, Wavelength converters,
Regenerators, OEO Switches, etc...), links (WDM systems) and end
systems (detectors, demodulators, etc...). The details of any local
configuration processes are out of the scope of this document.
From [WSON-Comp] we have the following list of WSON signal
characteristic information:
List 1. WSON Signal Characteristics
1. Optical tributary signal class (modulation format).
Bernstein et al. Expires April 22, 2010 [Page 4]
Internet-Draft WSON Signaling Extensions October 2009
2. FEC: whether forward error correction is used in the digital stream
and what type of error correcting code is used
3. Center frequency (wavelength)
4. Bit rate
5. G-PID: General Protocol Identifier for the information format
The first three items on this list can change as a WSON signal
traverses a network with regenerators, OEO switches, or wavelength
converters. An ability to control wavelength conversion already
exists in GMPLS signaling along with the ability to share client
signal type information (G-PID). In addition, bit rate is a standard
GMPLS signaling traffic parameter. It is referred to as Bandwidth
Encoding in [RFC3471]. This leaves two new parameters: modulation
format and FEC type, needed to fully characterize the optical signal.
3.2. Per LSP Network Element Processing Configuration
In addition to configuring a network element (NE) along an LSP to
input or output a signal with specific attributes, we may need to
signal the NE to perform specific processing, such as 3R
regeneration, on the signal at a particular NE. In [WSON-Comp] we
discussed two types of processing not currently covered by GMPLS:
(A) Regeneration (possibly different types)
(B) Fault and Performance Monitoring
(C) Attribute Conversion
The extensions here MUST provide for the configuration of these types
of processing at nodes along an LSP.
3.3. Bi-Directional Distributed Wavelength Assignment
WSON signaling MAY support distributed wavelength assignment
consistent with the wavelength continuity constraint for bi-
directional connections. The following two cases MAY be separately
supported: (a) Where the same wavelength is used for both upstream
and downstream directions, and (b) Where different wavelengths can be
used for both upstream and downstream directions.
The need for the same wavelength on both directions mainly comes from
the color constraint on some edges' hardware. In fact, the edges can
Bernstein et al. Expires April 22, 2010 [Page 5]
Internet-Draft WSON Signaling Extensions October 2009
be classified into two types, i.e. without and with the wavelength-
port mapping re-configurability.
Without the mapping re-configurability at edges, the edge nodes must
use the same wavelength in both directions. For example, (1)
transponders are only connected to AWGs (i.e. multiplexer/de-
multiplexer) ports directly and fixedly, or (2) transponders are
connected to the add/drop ports of ROADM and each port is mapped to a
dedicated wavelength fixedly.
On the other hand, with the mapping re-configurability at edges, the
edge nodes can use different wavelengths in different directions. For
example, in edge nodes, transponders are connected to add/drop ports
of colorless ROADM. Thus, the wavelength-port remapping problem can
be solved locally by appropriately configuring the colorless ROADM.
If the colorless ROADM consists of OXC and AWGs, the OXC is
configured appropriately.
The edges of data-plane in WSON can be constructed in different types
based on cost and flexibility concerns. Without re-configurability
we should consider the constraint of the same wavelength usage on
both directions, but have lower costs. While, with wavelength-port
mapping re-configurability we can relax the constraint, but have
higher costs.
These two types of edges will co-exist in WSON mesh, till all the
edges are unified by the same type. The existence of the first type
edges presents a requirement of the same wavelength usage on both
directions, which must be supported.
Moreover, if some carriers prefer an easy management lightpath usage,
say use the same wavelength on both directions to reduce the burden
on lightpath management, the same wavelength usage would be
beneficial.
In cases of equipment failure, etc., fast provisioning used in quick
recovery is critical to protect Carriers/Users against system loss.
This requires efficient signaling which supports distributed
wavelength assignment, in particular when the centralized wavelength
assignment capability is not available.
3.4. Distributed Wavelength Assignment Support
WSON signaling MAY support the selection of a specific distributed
wavelength assignment method.
Bernstein et al. Expires April 22, 2010 [Page 6]
Internet-Draft WSON Signaling Extensions October 2009
As discussed in the [WSON-Frame] a variety of different wavelength
assignment algorithms have been developed. A number of these are
suitable for use in distributed wavelength assignment. This feature
would allow the specification of a particular approach when more than
one are implemented in the systems along the path.
3.5. Out of Scope
This draft does not address signaling information related to optical
impairments.
4. WSON Signal Traffic Parameters, Attributes and Processing
As discussed in [WSON-Comp] single channel optical signals used in
WSONs are called "optical tributary signals" and come in a number of
classes characterized by modulation format and bit rate. Although
WSONs are fairly transparent to the signals they carry, to ensure
compatibility amongst various networks devices and end systems it can
be important to include key lightpath characteristics as traffic
parameters in signaling [WSON-Comp].
4.1. Traffic Parameters for Optical Tributary Signals
In [RFC3471] we see that the G-PID (client signal type) and bit rate
(byte rate) of the signals are defined as parameters and in [RFC3473]
they are conveyed Generalized Label Request object and the RSVP
SENDER_TSPEC/FLOWSPEC objects respectively.
4.2. Signal Attributes and Processing
Section 3.2. gave the requirements for signaling to indicate to a
particular NE along an LSP what type of processing to perform on an
optical signal or how to configure that NE to accept or transmit an
optical signal with particular attributes.
One way of accomplishing this is via a new EXPLICIT_ROUTE subobject.
Reference [RFC3209] defines the EXPLICIT_ROUTE object (ERO) and a
number of subobjects, while reference [RFC5420] defines general
mechanisms for dealing with additional LSP attributes. Although
reference [RFC5420] defines a RECORD_ROUTE object (RRO) attributes
subobject, it does not define an ERO subobject for LSP attributes.
Regardless of the exact coding for the ERO subobject conveying the
input, output, or processing instructions. This new "processing"
subobject would follow a subobject containing the IP address, or the
interface identifier [RFC3477], associated with the link on which it
is to be used along with any label subobjects [RFC3473].
Bernstein et al. Expires April 22, 2010 [Page 7]
Internet-Draft WSON Signaling Extensions October 2009
The contents of this new "processing" subobject would be a list of
TLVs that could include:
o Modulation Type TLV (input and/or output)
o FEC Type TLV (input and/or output)
o Processing Instruction TLV
Currently the only processing instruction TLV currently defined is
for regeneration. Possible encodings and values for these TLV are
given in below.
4.2.1. Modulation Type sub-TLV
The modulation type sub-TLV may come in two different formats: a
standard modulation field or a vendor specific modulation field. Both
start with the same 32 bit header shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|I| Modulation ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where S bit set to 1 indicates a standardized modulation format and S
bit set to 0 indicates a vendor specific modulation format. The
length is the length in bytes of the entire modulation type field.
Where I bit set to 1 indicates an input modulation format and where I
bit set to 0 indicates an output modulation format. Note that the
source modulation type is implied when I bit is set to 0 and that the
sink modulation type is implied when I bit is set to 1. For signaling
purposes only the output form (I=0) is needed.
The format for the standardized type is given by:
Bernstein et al. Expires April 22, 2010 [Page 8]
Internet-Draft WSON Signaling Extensions October 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|I| Modulation ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Possible additional modulation parameters depending upon |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: the modulation ID :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Modulation ID
Takes on the following currently defined values:
0 Reserved
1 optical tributary signal class NRZ 1.25G
2 optical tributary signal class NRZ 2.5G
3 optical tributary signal class NRZ 10G
4 optical tributary signal class NRZ 40G
5 optical tributary signal class RZ 40G
Note that future modulation types may require additional parameters
in their characterization.
The format for vendor specific modulation is given by:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|I| Vendor Modulation ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Any vendor specific additional modulation parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor Modulation ID
This is a vendor assigned identifier for the modulation type.
Bernstein et al. Expires April 22, 2010 [Page 9]
Internet-Draft WSON Signaling Extensions October 2009
Enterprise Number
A unique identifier of an organization encoded as a 32-bit integer.
Enterprise Numbers are assigned by IANA and managed through an IANA
registry [RFC2578].
Vendor Specific Additional parameters
There can be potentially additional parameters characterizing the
vendor specific modulation.
4.2.2. FEC Type sub-TLV
The FEC Type TLV indicates the FEC type output at particular node
along the LSP. The FEC type sub-TLV comes in two different types: a
standard FEC field or a vendor specific FEC field. Both start with
the same 32 bit header shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|I| FEC ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Possible additional FEC parameters depending upon |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: the FEC ID :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where S bit set to 1 indicates a standardized FEC format and S bit
set to 0 indicates a vendor specific FEC format. The length is the
length in bytes of the entire FEC type field.
Where the length is the length in bytes of the entire FEC type field.
Where I bit set to 1 indicates an input FEC format and where I bit
set to 0 indicates an output FEC format. Note that the source FEC
type is implied when I bit is set to 0 and that the sink FEC type is
implied when I bit is set to 1. Only the output form (I=0) is used in
signaling.
The format for standard FEC field is given by:
Bernstein et al. Expires April 22, 2010 [Page 10]
Internet-Draft WSON Signaling Extensions October 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|I| FEC ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Possible additional FEC parameters depending upon |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: the FEC ID :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Takes on the following currently defined values for the standard
FEC ID:
0 Reserved
1 G.709 RS FEC
2 G.709V compliant Ultra FEC
The format for vendor-specific FEC field is given by:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|I| Vendor FEC ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Any vendor specific additional FEC parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor FEC ID
This is a vendor assigned identifier for the FEC type.
Enterprise Number
A unique identifier of an organization encoded as a 32-bit integer.
Enterprise Numbers are assigned by IANA and managed through an IANA
registry [RFC2578].
Bernstein et al. Expires April 22, 2010 [Page 11]
Internet-Draft WSON Signaling Extensions October 2009
Vendor Specific Additional FEC parameters
There can be potentially additional parameters characterizing the
vendor specific FEC.
4.2.3. Regeneration Processing TLV
The Regeneration Processing TLV is used to indicate that this
particular node is to perform the specified type of regeneration
processing on the signal.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T | C | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where T bit indicates the type of regenerator:
T=0: Reserved
T=1: 1R Regenerator
T=2: 2R Regenerator
T=3: 3R Regenerator
Where C bit indicates the capability of regenerator:
C=0: Reserved
C=1: Fixed Regeneration Point
C=2: Selective Regeneration Pools
Note that the use of the C field is optional in signaling.
5. Bidirectional Lightpath using Same Wavelength
With the wavelength continuity constraint in CI-incapable [RFC3471]
WSONs, where the nodes in the networks cannot support wavelength
conversion, the same wavelength on each link along a unidirectional
lightpath should be reserved. Per the definition in [RFC3471], a
bidirectional lightpath can be seen as a pair of unidirectional
lightpaths, which are provisioned along the same route simultaneously
by the RSVP-TE signaling with Upstream Label and Label Set Objects in
Bernstein et al. Expires April 22, 2010 [Page 12]
Internet-Draft WSON Signaling Extensions October 2009
the messages [RFC3473]. This does not necessarily require the same
wavelength in both directions.
In addition to the wavelength continuity constraint, requirement 3.2
gives us another constraint on wavelength usage in data plane, in
particular, it requires the same wavelength to be used in both
directions.
The simplest and efficient way is to only define an extension to the
processing of Label Set [RFC3473], and leave the other processes
untouched. The issues related to this new functionality including an
LSP_ATTRIBUTES object defined in [RFC5420] and the new procedure are
described in the following sections. This approach would have a lower
blocking probability and a shorter provisioning time. In cases of
equipment failure, etc., fast provisioning used in quick recovery is
critical to protect Carriers/Users against system loss.
5.1. Using LSP_ATTRIBUTES Object
To trigger the new functionality at each GMPLS node, it is necessary
to notify the receiver the new type lightpath request. One multi-
purpose flag/attribute parameter container object called
LSP_ATTRIBUTES object and related mechanism defined in [RFC5420] meet
this requirement. One bit in Attributes Flags TLV which indicates the
new type lightpath, say, the bidirectional same wavelength lightpath
will be present in an LSP_ATTRIBUTES object. Please refer to
[RFC5420] for detailed descriptions of the Flag and related issues.
5.2. Bidirectional Lightpath Signaling Procedure
Considering the system configuration mentioned above, it is needed to
add a new function into RSVP-TE to support bidirectional lightpath
with same wavelength on both directions.
The lightpath setup procedure is described below:
1. Ingress node adds the new type lightpath indication in an
LSP_ATTRIBUTES object. It is propagated in the Path message in
the same way as that of a Label Set object for downstream;
2. On reception of a Path message containing both the new type
lightpath indication in an LSP_ATTRIBUTES object and Label Set
object, the receiver of message along the path checks the local
LSP database to see if the Label Set TLVs are acceptable on both
directions jointly. If there are acceptable wavelengths, then
copy the values of them into new Label Set TLVs, and forward the
Path message to the downstream node. Otherwise the Path message
Bernstein et al. Expires April 22, 2010 [Page 13]
Internet-Draft WSON Signaling Extensions October 2009
will be terminated, and a PathErr message with a "Routing
problem/Label Set" indication will be generated;
3. On reception of a Path message containing both such a new type
lightpath indication in an LSP_ATTRIBUTES object and an Upstream
Label object, the receiver MUST terminate the Path message using
a PathErr message with Error Code "Unknown Attributes TLV" and
Error Value set to the value of the new type lightpath TLV type
code;
4. On reception of a Path message containing both the new type
lightpath indication in an LSP_ATTRIBUTES object and Label Set
object, the egress node verifies whether the Label Set TLVs are
acceptable, if one or more wavelengths are available on both
directions, then any one available wavelength could be selected.
A Resv message is generated and propagated to upstream node;
5. When a Resv message is received at an intermediate node, if it is
a new type lightpath, the intermediate node allocates the label
to interfaces on both directions and update internal database for
this bidirectional same wavelength lightpath, then configures the
local ROADM or OXC on both directions.
Except the procedure related to Label Set object, the other processes
will be left untouched.
5.3. Backward Compatibility Considerations
Due to the introduction of new processing on Label Set object, it is
required that each node in the lightpath is able to recognize the new
type lightpath indication Flag carried by an LSP_ATTRIBUTES object,
and deal with the new Label Set operation correctly. It is noted
that this new extension is not backward compatible.
According to the descriptions in [RFC5420], an LSR that does not
recognize a TLV type code carried in this object MUST reject the Path
message using a PathErr message with Error Code "Unknown Attributes
TLV" and Error Value set to the value of the Attributes Flags TLV
type code.
An LSR that does not recognize a bit set in the Attributes Flags TLV
MUST reject the Path message using a PathErr message with Error Code
"Unknown Attributes Bit" and Error Value set to the bit number of the
new type lightpath Flag in the Attributes Flags.The reader is
Bernstein et al. Expires April 22, 2010 [Page 14]
Internet-Draft WSON Signaling Extensions October 2009
referred to the detailed backward compatibility considerations
expressed in [RFC5420].
6. Bidirectional Lightpath using Different Wavelengths
TBD
7. RWA Related
7.1. Wavelength Assignment Method Selection
As discussed in [HZang00] a number of different wavelength assignment
algorithms maybe employed. In addition as discussed in [WSON-Frame]
the wavelength assignment can be either for a unidirectional
lightpath or for a bidirectional lightpath constrained to use the
same lambda in both directions. A simple TLV could be used to
indication wavelength assignment directionality and wavelength
assignment method. This would be placed in an LSP_REQUIRED_ATTRIBUTES
object per [RFC5420]. The use of a TLV in the LSP required attributes
object was pointed out in [Xu].
[TO DO: The directionality stuff needs to be reconciled with the
earlier material]
Directionality: 0 unidirectional, 1 bidirectional
Wavelength Assignment Method: 0 unspecified (any), 1 First-Fit, 2
Random, 3 Least-Loaded (multi-fiber). Others TBD.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Direction | WA Method | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8. Security Considerations
This document has no requirement for a change to the security models
within GMPLS and associated protocols. That is the OSPF-TE, RSVP-TE,
and PCEP security models could be operated unchanged.
However satisfying the requirements for RWA using the existing
Bernstein et al. Expires April 22, 2010 [Page 15]
Internet-Draft WSON Signaling Extensions October 2009
protocols may significantly affect the loading of those protocols.
This makes the operation of the network more vulnerable to denial of
service attacks. Therefore additional care maybe required to ensure
that the protocols are secure in the WSON environment.
Furthermore the additional information distributed in order to
address the RWA problem represents a disclosure of network
capabilities that an operator may wish to keep private. Consideration
should be given to securing this information.
9. IANA Considerations
TBD. Once finalized in our approach we will need identifiers for such
things and modulation types, modulation parameters, wavelength
assignment methods, etc...
10. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Bernstein et al. Expires April 22, 2010 [Page 16]
Internet-Draft WSON Signaling Extensions October 2009
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A.
Ayyangar, " Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2006.
11.2. Informative References
[WSON-Comp] G. Bernstein, Y. Lee, Ben Mack-Crane, "WSON Signal
Characteristics and Network Element Compatibility
Constraints for GMPLS", work in progress: draft-bernstein-
ccamp-wson-signal.
[WSON-CompOSPF] Y. Lee, G. Bernstein, "OSPF Enhancement for Signal
and Network Element Compatibility for Wavelength Switched
Optical Networks", work in progress: draft-lee-ccamp-wson-
signal-compatibility-OSPF.
Bernstein et al. Expires April 22, 2010 [Page 17]
Internet-Draft WSON Signaling Extensions October 2009
[WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS
and PCE Control of Wavelength Switched Optical Networks",
work in progress: draft-bernstein-ccamp-wavelength-
switched-03.txt, February 2008.
[HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing and
wavelength assignment approaches for wavelength-routed
optical WDM networks", Optical Networks Magazine, January
2000.
[Xu] S. Xu, H. Harai, and D. King, "Extensions to GMPLS RSVP-TE
for Bidirectional Lightpath the Same Wavelength", work in
progress: draft-xu-rsvpte-bidir-wave-01, November 2007.
[Winzer06] Peter J. Winzer and Rene-Jean Essiambre, "Advanced
Optical Modulation Formats", Proceedings of the IEEE, vol.
94, no. 5, pp. 952-985, May 2006.
[G.959.1] ITU-T Recommendation G.959.1, Optical Transport Network
Physical Layer Interfaces, March 2006.
[G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM
applications: DWDM frequency grid, June 2002.
[G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM
applications: CWDM wavelength grid, December 2003.
[G.Sup43] ITU-T Series G Supplement 43, Transport of IEEE 10G base-R
in optical transport networks (OTN), November 2006.
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
2006.
Bernstein et al. Expires April 22, 2010 [Page 18]
Internet-Draft WSON Signaling Extensions October 2009
Author's Addresses
Greg M. Bernstein (editor)
Grotto Networking
Fremont California, USA
Phone: (510) 573-2237
Email: gregb@grotto-networking.com
Nicola Andriolli
Scuola Superiore Sant'Anna, Pisa, Italy
Email: a.giorgetti@sssup.it
Aessio Giorgetti
Scuola Superiore Sant'Anna, Pisa, Italy
Email: a.giorgetti@sssup.it
Lin Guo
Key Laboratory of Optical Communication and Lightwave Technologies
Ministry of Education
P.O. Box 128, Beijing University of Posts and Telecommunications,
P.R.China
Email: guolintom@gmail.com
Hiroaki Harai
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi, Koganei,
Tokyo, 184-8795 Japan
Phone: +81 42-327-5418
Email: harai@nict.go.jp
Yuefeng Ji
Key Laboratory of Optical Communication and Lightwave Technologies
Ministry of Education
P.O. Box 128, Beijing University of Posts and Telecommunications,
P.R.China
Email: jyf@bupt.edu.cn
Daniel King (editor)
Old Dog Consulting
Email: daniel@olddog.co.uk
Young Lee (editor)
Huawei Technologies
Bernstein et al. Expires April 22, 2010 [Page 19]
Internet-Draft WSON Signaling Extensions October 2009
1700 Alma Drive, Suite 100
Plano, TX 75075
USA
Phone: (972) 509-5599 (x2240)
Email: ylee@huawei.com
Sugang Xu
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi, Koganei,
Tokyo, 184-8795 Japan
Phone: +81 42-327-6927
Email: xsg@nict.go.jp
Intellectual Property Statement
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
Bernstein et al. Expires April 22, 2010 [Page 20]
Internet-Draft WSON Signaling Extensions October 2009
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bernstein et al. Expires April 22, 2010 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-23 22:43:04 |