draft-ietf-ccamp-wson-signaling-02.txt   draft-ietf-ccamp-wson-signaling-03.txt 
Network Working Group G. Bernstein Network Working Group G. Bernstein
Internet Draft Grotto Networking Internet Draft Grotto Networking
Intended status: Standards Track Sugang Xu Intended status: Standards Track Sugang Xu
NICT NICT
Expires: March 2012 Y.Lee Expires: September 2012 Y.Lee
Huawei Huawei
G. Martinelli G. Martinelli
Cisco Cisco
Hiroaki Harai Hiroaki Harai
NICT NICT
September 13, 2011 March 7, 2012
Signaling Extensions for Wavelength Switched Optical Networks Signaling Extensions for Wavelength Switched Optical Networks
draft-ietf-ccamp-wson-signaling-02.txt draft-ietf-ccamp-wson-signaling-03.txt
Abstract Abstract
This memo provides extensions to Generalized Multi-Protocol Label This memo provides extensions to Generalized Multi-Protocol Label
Switching (GMPLS) signaling for control of wavelength switched Switching (GMPLS) signaling for control of wavelength switched
optical networks (WSON). Such extensions are necessary in WSONs optical networks (WSON). Such extensions are necessary in WSONs
under a number of conditions including: (a) when optional processing, under a number of conditions including: (a) when optional
such as regeneration, must be configured to occur at specific nodes processing, such as regeneration, must be configured to occur at
along a path, (b) where equipment must be configured to accept an specific nodes along a path, (b) where equipment must be configured
optical signal with specific attributes, or (c) where equipment must to accept an optical signal with specific attributes, or (c) where
be configured to output an optical signal with specific attributes. equipment must be configured to output an optical signal with
In addition this memo provides mechanisms to support distributed specific attributes. In addition this memo provides mechanisms to
wavelength assignment with bidirectional LSPs, and choice in support distributed wavelength assignment with bidirectional LSPs,
distributed wavelength assignment algorithms. These extensions build and choice in distributed wavelength assignment algorithms. These
on previous work for the control of lambda and G.709 based networks. extensions build on previous work for the control of lambda and
G.709 based networks.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with
provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 13, 2007. This Internet-Draft will expire on September 7, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with
to this document. Code Components extracted from this document must respect to this document. Code Components extracted from this
include Simplified BSD License text as described in Section 4.e of document must include Simplified BSD License text as described in
the Trust Legal Provisions and are provided without warranty as Section 4.e of the Trust Legal Provisions and are provided without
described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Terminology....................................................3 2. Terminology....................................................3
3. Requirements for WSON Signaling................................4 3. Requirements for WSON Signaling................................4
3.1. WSON Signal Characterization..............................4 3.1. WSON Signal Characterization..............................4
3.2. Per LSP Network Element Processing Configuration..........5 3.2. Per LSP Network Element Processing Configuration..........5
3.3. Bi-Directional Distributed Wavelength Assignment..........5 3.3. Bi-Directional WSON LSPs..................................5
3.4. Distributed Wavelength Assignment Support.................6 3.4. Distributed Wavelength Assignment Support.................6
3.5. Out of Scope..............................................6 3.5. Out of Scope..............................................6
4. WSON Signal Traffic Parameters, Attributes and Processing......6 4. WSON Signal Traffic Parameters, Attributes and Processing......6
4.1. Traffic Parameters for Optical Tributary Signals..........6 4.1. Traffic Parameters for Optical Tributary Signals..........6
4.2. Signal Attributes and Processing..........................6 4.2. Signal Attributes and Processing..........................7
4.2.1. Modulation Type sub-TLV..............................7 4.2.1. WSON Processing Object Encoding......................8
4.2.2. FEC Type sub-TLV.....................................9 5. Bidirectional Lightpath Setup..................................8
4.2.3. Regeneration Processing TLV.........................12 6. RWA Related....................................................9
5. Bidirectional Lightpath Setup.................................13 6.1. Wavelength Assignment Method Selection....................9
5.1. Possible Solutions for Bidirectional Lightpath...........13 7. Security Considerations.......................................10
5.2. Bidirectional Lightpath Signaling Procedure..............14 8. IANA Considerations...........................................11
5.3. Backward Compatibility Considerations....................15 9. Acknowledgments...............................................11
10. References...................................................12
6. RWA Related...................................................15 10.1. Normative References....................................12
6.1. Wavelength Assignment Method Selection...................15 10.2. Informative References..................................12
7. Security Considerations.......................................16 Author's Addresses...............................................14
8. IANA Considerations...........................................17 Intellectual Property Statement..................................15
9. Acknowledgments...............................................17 Disclaimer of Validity...........................................16
10. References...................................................18
10.1. Normative References....................................18
10.2. Informative References..................................18
Author's Addresses...............................................21
Intellectual Property Statement..................................22
Disclaimer of Validity...........................................23
1. Introduction 1. Introduction
This memo provides extensions to Generalized Multi-Protocol Label This memo provides extensions to Generalized Multi-Protocol Label
Switching (GMPLS) signaling for control of wavelength switched Switching (GMPLS) signaling for control of wavelength switched
optical networks (WSON). Fundamental extensions are given to permit optical networks (WSON). Fundamental extensions are given to permit
simultaneous bi-directional wavelength assignment while more advanced simultaneous bi-directional wavelength assignment while more
extensions are given to support the networks described in [RFC6163] advanced extensions are given to support the networks described in
which feature connections requiring configuration of input, output, [RFC6163] which feature connections requiring configuration of
and general signal processing capabilities at a node along a LSP 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 These extensions build on previous work for the control of lambda
G.709 based networks. and G.709 based networks.
2. Terminology 2. Terminology
CWDM: Coarse Wavelength Division Multiplexing. CWDM: Coarse Wavelength Division Multiplexing.
DWDM: Dense Wavelength Division Multiplexing. DWDM: Dense Wavelength Division Multiplexing.
FOADM: Fixed Optical Add/Drop Multiplexer. FOADM: Fixed Optical Add/Drop Multiplexer.
ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port
skipping to change at page 4, line 24 skipping to change at page 4, line 24
wavelength and electronic components, which converts electronic wavelength and electronic components, which converts electronic
signals into optical signals. signals into optical signals.
Optical Responder: A device that has both optical and electronic Optical Responder: A device that has both optical and electronic
components. It detects optical signals and converts optical signals components. It detects optical signals and converts optical signals
into electronic signals. into electronic signals.
Optical Transponder: A device that has both an optical transmitter Optical Transponder: A device that has both an optical transmitter
and an optical responder. and an optical responder.
Optical End Node: The end of a wavelength (optical lambdas) lightpath Optical End Node: The end of a wavelength (optical lambdas)
in the data plane. It may be equipped with some optical/electronic lightpath in the data plane. It may be equipped with some
devices such as wavelength multiplexers/demultiplexer (e.g. AWG), optical/electronic devices such as wavelength
optical transponder, etc., which are employed to transmit/terminate multiplexers/demultiplexer (e.g. AWG), optical transponder, etc.,
the optical signals for data transmission. which are employed to transmit/terminate the optical signals for
data transmission.
3. Requirements for WSON Signaling 3. Requirements for WSON Signaling
The following requirements for GMPLS based WSON signaling are in The following requirements for GMPLS based WSON signaling are in
addition to the functionality already provided by existing GMPLS addition to the functionality already provided by existing GMPLS
signaling mechanisms. signaling mechanisms.
3.1. WSON Signal Characterization 3.1. WSON Signal Characterization
WSON signaling MUST convey sufficient information characterizing the WSON signaling MUST convey sufficient information characterizing the
signal to allow systems along the path to determine compatibility and signal to allow systems along the path to determine compatibility
perform any required local configuration. Examples of such systems and perform any required local configuration. Examples of such
include intermediate nodes (ROADMs, OXCs, Wavelength converters, systems include intermediate nodes (ROADMs, OXCs, Wavelength
Regenerators, OEO Switches, etc...), links (WDM systems) and end converters, Regenerators, OEO Switches, etc...), links (WDM systems)
systems (detectors, demodulators, etc...). The details of any local and end systems (detectors, demodulators, etc...). The details of
configuration processes are out of the scope of this document. any local configuration processes are out of the scope of this
document.
From [RFC6163] we have the following list of WSON signal From [RFC6163] we have the following list of WSON signal
characteristic information: characteristic information:
List 1. WSON Signal Characteristics List 1. WSON Signal Characteristics
1. Optical tributary signal class (modulation format). 1. Optical tributary signal class (modulation format).
2. FEC: whether forward error correction is used in the digital stream 2. FEC: whether forward error correction is used in the digital
and what type of error correcting code is used stream and what type of error correcting code is used
3. Center frequency (wavelength) 3. Center frequency (wavelength)
4. Bit rate 4. Bit rate
5. G-PID: General Protocol Identifier for the information format 5. G-PID: General Protocol Identifier for the information format
The first three items on this list can change as a WSON signal The first three items on this list can change as a WSON signal
traverses a network with regenerators, OEO switches, or wavelength traverses a network with regenerators, OEO switches, or wavelength
converters. An ability to control wavelength conversion already converters. An ability to control wavelength conversion already
exists in GMPLS signaling along with the ability to share client exists in GMPLS signaling along with the ability to share client
signal type information (G-PID). In addition, bit rate is a standard signal type information (G-PID). In addition, bit rate is a standard
GMPLS signaling traffic parameter. It is referred to as Bandwidth GMPLS signaling traffic parameter. It is referred to as Bandwidth
Encoding in [RFC3471]. This leaves two new parameters: modulation Encoding in [RFC3471]. This leaves two new parameters: modulation
format and FEC type, needed to fully characterize the optical signal. format and FEC type, needed to fully characterize the optical
signal.
3.2. Per LSP Network Element Processing Configuration 3.2. Per LSP Network Element Processing Configuration
In addition to configuring a network element (NE) along an LSP to In addition to configuring a network element (NE) along an LSP to
input or output a signal with specific attributes, we may need to input or output a signal with specific attributes, we may need to
signal the NE to perform specific processing, such as 3R signal the NE to perform specific processing, such as 3R
regeneration, on the signal at a particular NE. In [RFC6163] we regeneration, on the signal at a particular NE. In [RFC6163] we
discussed three types of processing not currently covered by GMPLS: discussed three types of processing not currently covered by GMPLS:
(A) Regeneration (possibly different types) (A) Regeneration (possibly different types)
(B) Fault and Performance Monitoring (B) Fault and Performance Monitoring
(C) Attribute Conversion (C) Attribute Conversion
The extensions here MUST provide for the configuration of these types The extensions here MUST provide for the configuration of these
of processing at nodes along an LSP. types of processing at nodes along an LSP.
3.3. Bi-Directional Distributed Wavelength Assignment 3.3. Bi-Directional WSON LSPs
WSON signaling MAY support distributed wavelength assignment WSON signaling MAY support LSP setup consistent with the wavelength
consistent with the wavelength continuity constraint for bi- continuity constraint for bi-directional connections. The following
directional connections. The following cases MAY be separately cases MAY be separately supported:
supported:
(a)Where the same wavelength is used for both upstream and downstream (a) Where the same wavelength is used for both upstream and
directions downstream directions
(b)Where different wavelengths can be used for both upstream and (b) Where different wavelengths can be used for both upstream and
downstream directions. downstream directions.
3.4. Distributed Wavelength Assignment Support (Editor's Note: an evaluation of current GMPLS bidirectional
solutions should be evaluated if they would fit to the current WSON
needs.)
As discussed in [HZang00] and [Sambo11] different computational 3.4. Distributed Wavelength Assignment Support
approaches for distributed wavelength assignment are available. Hence
it may be advantageous to allow the specification of a particular
approach when more than one mechanism is implemented in the systems
along the path.
WSON signaling MAY support the selection of a specific distributed WSON signaling MAY support the selection of a specific distributed
wavelength assignment method. wavelength assignment method.
This method is beneficial in cases of equipment failure, etc., where
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.
As discussed in the [RFC6163] different computational approaches for
wavelength assignment are available. One method is the use of
distributed wavelength assignment. This feature would allow the
specification of a particular approach when more than one is
implemented in the systems along the path.
3.5. Out of Scope 3.5. Out of Scope
This draft does not address signaling information related to optical This draft does not address signaling information related to optical
impairments. impairments.
4. WSON Signal Traffic Parameters, Attributes and Processing 4. WSON Signal Traffic Parameters, Attributes and Processing
As discussed in [RFC6163] single channel optical signals used in As discussed in [RFC6163] single channel optical signals used in
WSONs are called "optical tributary signals" and come in a number of WSONs are called "optical tributary signals" and come in a number of
classes characterized by modulation format and bit rate. Although classes characterized by modulation format and bit rate. Although
WSONs are fairly transparent to the signals they carry, to ensure WSONs are fairly transparent to the signals they carry, to ensure
compatibility amongst various networks devices and end systems it can compatibility amongst various networks devices and end systems it
be important to include key lightpath characteristics as traffic can be important to include key lightpath characteristics as traffic
parameters in signaling [RFC6163]. parameters in signaling [RFC6163].
4.1. Traffic Parameters for Optical Tributary Signals 4.1. Traffic Parameters for Optical Tributary Signals
In [RFC3471] we see that the G-PID (client signal type) and bit rate 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] (byte rate) of the signals are defined as parameters and in
they are conveyed Generalized Label Request object and the RSVP
SENDER_TSPEC/FLOWSPEC objects respectively. [RFC3473] they are conveyed Generalized Label Request object and the
RSVP SENDER_TSPEC/FLOWSPEC objects respectively.
4.2. Signal Attributes and Processing 4.2. Signal Attributes and Processing
Section 3.2. gave the requirements for signaling to indicate to a 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 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 or how to configure that NE to accept or transmit an
optical signal with particular attributes. optical signal with particular attributes.
One way of accomplishing this is via a new EXPLICIT_ROUTE subobject. One way of accomplishing this is via a new EXPLICIT_ROUTE subobject.
Reference [RFC3209] defines the EXPLICIT_ROUTE object (ERO) and a Reference [RFC3209] defines the EXPLICIT_ROUTE object (ERO) and a
skipping to change at page 7, line 15 skipping to change at page 7, line 28
mechanisms for dealing with additional LSP attributes. Although mechanisms for dealing with additional LSP attributes. Although
reference [RFC5420] defines a RECORD_ROUTE object (RRO) attributes reference [RFC5420] defines a RECORD_ROUTE object (RRO) attributes
subobject, it does not define an ERO subobject for LSP attributes. subobject, it does not define an ERO subobject for LSP attributes.
Regardless of the exact coding for the ERO subobject conveying the Regardless of the exact coding for the ERO subobject conveying the
input, output, or processing instructions. This new "processing" input, output, or processing instructions. This new "processing"
subobject would follow a subobject containing the IP address, or the subobject would follow a subobject containing the IP address, or the
interface identifier [RFC3477], associated with the link on which it interface identifier [RFC3477], associated with the link on which it
is to be used along with any label subobjects [RFC3473]. is to be used along with any label subobjects [RFC3473].
The contents of this new "processing" subobject would be a list of The WSON Signal Processing object is defined as an LSP_ATTRIBUTES
TLVs that could include: and extends the PATH message. It is defined as the following:
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. The [WSON-Info] and [WSON-Encode] provides the
details for these specifics sub-TLVs.
Possible encodings and values for these TLV are given in below.
4.2.1. Modulation Type sub-TLV
The encoding for modulation type sub-TLV is defined in [WSON-Encode]
Section 4.2.1.
It 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:
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.
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 encoding for FEC Type TLV is defined in [WSON-Encode] Section
4.3.1.
It 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:
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
3 G.975.1 Concatenated FEC
(RS(255,239)/CSOC(n0/k0=7/6,J=8))
4 G.975.1 Concatenated FEC (BCH(3860,3824)/BCH(2040,1930))
5 G.975.1 Concatenated FEC (RS(1023,1007)/BCH(2407,1952))
6 G.975.1 Concatenated FEC (RS(1901,1855)/Extended Hamming
Product Code (512,502)X(510,500))
7 G.975.1 LDPC Code
8 G.975.1 Concatenated FEC (Two orthogonally concatenated
BCH codes)
9 G.975.1 RS(2720,2550)
10 G.975.1 Concatenated FEC (Two interleaved extended BCH
(1020,988) codes)
Where RS stands for Reed-Solomon and BCH for Bose-Chaudhuri-
Hocquengham.
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. <WSON Processing> ::= <hop information> <Transmitter Capabilities>
<Receiver Capabilities> [<RegenerationCapabilities>]
Enterprise Number <Receiver Capabilities> ::= <ModulationTypeList> <FECTypeList>
A unique identifier of an organization encoded as a 32-bit integer. <BitRateRange>
Enterprise Numbers are assigned by IANA and managed through an IANA
registry [RFC2578].
Vendor Specific Additional FEC parameters <Transmitter Capabilities> ::=
There can be potentially additional parameters characterizing the (ModulationTypeList> <FECTypeList> <BitRateRange>
vendor specific FEC.
4.2.3. Regeneration Processing TLV Where:
The Regeneration Processing TLV is used to indicate that this <hop information>: Ipv4,Ipv6 address. Note: this not required if
particular node is to perform the specified type of regeneration WSON Processing object become part of the ERO
processing on the signal.
0 1 2 3 <Transmitter Capabilities> is defined in [WSON-Encode].
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: <ReceiverCapabilities> is defined in [WSON-Encode].
T=0: Reserved <ModulationTypeList> is defined in[WSON-Encode]
T=1: 1R Regenerator <FECTypeList> is defined in [WSON-Encode]
T=2: 2R Regenerator <BitRateRange> is defined in [WSON-Encode]
T=3: 3R Regenerator <RegenerationCapabilities> is defined in [WSON-Encode]
Where C bit indicates the capability of regenerator: <RegenerationCapabilities> are only applied in the intermediate
nodes of the LSP. The head and tail nodes will ignore regeneration
capability processing.
C=0: Reserved 4.2.1. WSON Processing Object Encoding
C=1: Fixed Regeneration Point 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C=2: Selective Regeneration Pools Type: to be defined by IANA
Note that the use of the C field is optional in signaling. Value: sub-TLVS according to section 4.1.
5. Bidirectional Lightpath Setup 5. Bidirectional Lightpath Setup
With the wavelength continuity constraint in CI-incapable [RFC3471] With the wavelength continuity constraint in CI-incapable [RFC3471]
WSONs, where the nodes in the networks cannot support wavelength WSONs, where the nodes in the networks cannot support wavelength
conversion, the same wavelength on each link along a unidirectional conversion, the same wavelength on each link along a unidirectional
lightpath should be reserved. In addition to the wavelength lightpath should be reserved. In addition to the wavelength
continuity constraint, requirement 3.2 gives us another constraint on continuity constraint, requirement 3.2 gives us another constraint
wavelength usage in data plane, in particular, it requires the same on wavelength usage in data plane, in particular, it requires the
wavelength to be used in both directions. [RFC6163] in section 6.1 same wavelength to be used in both directions. [RFC6163] in section
reports on the implication to GMPLS signaling related to both bi- 6.1 reports on the implication to GMPLS signaling related to both
directionality and Distributed Wavelengths Assignment. bi-directionality and Distributed Wavelengths Assignment.
5.1. Possible Solutions for Bidirectional Lightpath
A first classification is using a unique bidirectional LSP (as
defined by [RFC3471]) two unidirectional LSPs as per [RFC2205]
approach, so possible options are the following:
o Bidirectional LSP
1. Current [RFC3471], [RFC3473] co-routed approach. The
label distribution is based on Label_Set and
Upstream_Label objects. In case of specific constraints
such as the same wavelengths in both directions, it may
require several signaling attempts using information from
the Acceptable_Label_Set received from path error
messages.
2. Using a specific LSP_ATTRIBUTE or a newly defined
Upstream_Label_Set object. This mechanism seems to be more
efficient (i.e. one signaling attempt) in case of
distributed wavelength assignment and same wavelength in
both directions.
o Two Unidirectional LSPs. This solution has been always
available as per [RFC3209] however recent work introduces the
association concept [RFC4872] and [ASSOC-Info]. Recent
transport evolutions [ASSOC-ext] provide a way to associate two
unidirectional LSPs as a bidirectional LSP. In line with this,
a small extension can make this approach work for the WSON
case.
5.2. Bidirectional Lightpath Signaling Procedure
[TO BE UPDATED ACCORDING TO THE BIDIRECTIONAL METHOD CHOOSEN FOR WSON
either new objects or assoc ]
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
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 Current GMPLS solution defines a bidirectional LSP (as defined by
recognize a TLV type code carried in this object MUST reject the Path [RFC3471]). The label distribution is based on Label_Set and
message using a PathErr message with Error Code "Unknown Attributes Upstream_Label objects. In case of specific constraints such as the
TLV" and Error Value set to the value of the Attributes Flags TLV same wavelengths in both directions, it may require several
type code. signaling attempts using information from the Acceptable_Label_Set
received from path error messages.
An LSR that does not recognize a bit set in the Attributes Flags TLV Some implementations may prefer using two unidirectional LSPs. This
MUST reject the Path message using a PathErr message with Error Code solution has been always available as per [RFC3209] however recent
"Unknown Attributes Bit" and Error Value set to the bit number of the work introduces the association concept [RFC4872] and [ASSOC-Info].
new type lightpath Flag in the Attributes Flags. The reader is Recent transport evolutions [ASSOC-ext] provide a way to associate
referred to the detailed backward compatibility considerations two unidirectional LSPs as a bidirectional LSP. In line with this, a
expressed in [RFC5420]. small extension can make this approach work for the WSON case.
6. RWA Related 6. RWA Related
6.1. Wavelength Assignment Method Selection 6.1. Wavelength Assignment Method Selection
Routing + Distributed wavelength assignment (R+DWA) is one of the Routing + Distributed wavelength assignment (R+DWA) is one of the
options defined by the [RFC6163]. The output from the routing options defined by the [RFC6163]. The output from the routing
function will be a path but the wavelength will be selected on a hop- function will be a path but the wavelength will be selected on a
by-hop basis. hop-by-hop basis.
Under this hypothesis the node initiating the signaling process needs Under this hypothesis the node initiating the signaling process
to declare its own wavelength availability (through a label_set needs to declare its own wavelength availability (through a
object). Each intermediate node may delete some labels due to label_set object). Each intermediate node may delete some labels due
connectivity constraints or its own assignment policy. At the end, to connectivity constraints or its own assignment policy. At the
the destination node has to make the final decision on the wavelength end, the destination node has to make the final decision on the
assignment among the ones received through the signaling process. wavelength assignment among the ones received through the signaling
process.
As discussed in [HZang00] and [Sambo11] a number of different As discussed in [HZang00] a number of different wavelength
wavelength assignment algorithms maybe employed. In addition as assignment algorithms maybe employed. In addition as discussed in
discussed in [RFC6163] the wavelength assignment can be either for a
unidirectional lightpath or for a bidirectional lightpath constrained [RFC6163] the wavelength assignment can be either for a
to use the same lambda in both directions. 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 A simple TLV could be used to indication wavelength assignment
directionality and wavelength assignment method. This would be placed directionality and wavelength assignment method. This would be
in an LSP_REQUIRED_ATTRIBUTES object per [RFC5420]. The use of a TLV placed in an LSP_REQUIRED_ATTRIBUTES object per [RFC5420]. The use
in the LSP required attributes object was pointed out in [Xu]. 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 [TO DO: The directionality stuff needs to be reconciled with the
earlier material] earlier material]
Unique Wavelength: 0 same wavelength in both directions, 1 may use Unique Wavelength: 0 same wavelength in both directions, 1 may use
different wavelengths [TBD: shall we use only 1 bit] different wavelengths [TBD: shall we use only 1 bit]
Wavelength Assignment Method: 0 unspecified (any), 1 First-Fit, 2 Wavelength Assignment Method: 0 unspecified (any), 1 First-Fit, 2
Random, 3 Least-Loaded (multi-fiber). Others TBD. Random, 3 Least-Loaded (multi-fiber). Others TBD.
skipping to change at page 16, line 39 skipping to change at page 10, line 44
and PCEP security models could be operated unchanged. and PCEP security models could be operated unchanged.
However satisfying the requirements for RWA using the existing However satisfying the requirements for RWA using the existing
protocols may significantly affect the loading of those protocols. protocols may significantly affect the loading of those protocols.
This makes the operation of the network more vulnerable to denial of This makes the operation of the network more vulnerable to denial of
service attacks. Therefore additional care maybe required to ensure service attacks. Therefore additional care maybe required to ensure
that the protocols are secure in the WSON environment. that the protocols are secure in the WSON environment.
Furthermore the additional information distributed in order to Furthermore the additional information distributed in order to
address the RWA problem represents a disclosure of network address the RWA problem represents a disclosure of network
capabilities that an operator may wish to keep private. Consideration capabilities that an operator may wish to keep private.
should be given to securing this information. Consideration should be given to securing this information.
8. IANA Considerations 8. IANA Considerations
TBD. Once finalized in our approach we will need identifiers for such TBD. Once finalized in our approach we will need identifiers for
things and modulation types, modulation parameters, wavelength such things and modulation types, modulation parameters, wavelength
assignment methods, etc... assignment methods, etc...
9. Acknowledgments 9. Acknowledgments
Anyone who provide comments and helpful inputs Anyone who provide comments and helpful inputs
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 18, line 40 skipping to change at page 12, line 40
in Resource ReSerVation Protocol - Traffic Engineering in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003. (RSVP-TE)", RFC 3477, January 2003.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A.
Ayyangar, " Encoding of Attributes for MPLS LSP Ayyangar, " Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2006. Engineering (RSVP-TE)", RFC 5420, February 2006.
10.2. Informative References 10.2. Informative References
[RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and [WSON-CompOSPF] Y. Lee, G. Bernstein, "OSPF Enhancement for Signal
PCE Control of Wavelength Switched Optical Networks", RFC and Network Element Compatibility for Wavelength Switched
6163, April, 2011. Optical Networks", work in progress: draft-lee-ccamp-wson-
signal-compatibility-OSPF.
[WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and
Wavelength Assignment Information Model for Wavelength
Switched Optical Networks", draft-ietf-ccamp-rwa-info
work in progress.
[WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS
Wavelength Assignment Information Encoding for Wavelength and PCE Control of Wavelength Switched Optical Networks",
Switched Optical Networks", draft-ietf-ccamp-rwa-wson- work in progress: draft-bernstein-ccamp-wavelength-
encode, work in progress. switched-03.txt, February 2008.
[HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing and [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing
wavelength assignment approaches for wavelength-routed and wavelength assignment approaches for wavelength-routed
optical WDM networks", Optical Networks Magazine, January optical WDM networks", Optical Networks Magazine, January
2000. 2000.
[Sambo11] "Wavelength Preference in GMPLS-controlled Wavelength
Switched Optical Networks," 01-Sep-2011. [Online].
Available:
http://macrothink.org/journal/index.php/npa/article/view/81
9/0.
[Xu] S. Xu, H. Harai, and D. King, "Extensions to GMPLS RSVP-TE [Xu] S. Xu, H. Harai, and D. King, "Extensions to GMPLS RSVP-TE
for Bidirectional Lightpath the Same Wavelength", work in for Bidirectional Lightpath the Same Wavelength", work in
progress: draft-xu-rsvpte-bidir-wave-01, November 2007. progress: draft-xu-rsvpte-bidir-wave-01, November 2007.
[Winzer06] Peter J. Winzer and Rene-Jean Essiambre, "Advanced [Winzer06] Peter J. Winzer and Rene-Jean Essiambre, "Advanced
Optical Modulation Formats", Proceedings of the IEEE, vol. Optical Modulation Formats", Proceedings of the IEEE, vol.
94, no. 5, pp. 952-985, May 2006. 94, no. 5, pp. 952-985, May 2006.
[G.959.1] ITU-T Recommendation G.959.1, Optical Transport Network [G.959.1] ITU-T Recommendation G.959.1, Optical Transport Network
Physical Layer Interfaces, March 2006. Physical Layer Interfaces, March 2006.
[G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM
applications: DWDM frequency grid, June 2002. applications: DWDM frequency grid, June 2002.
[G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM
applications: CWDM wavelength grid, December 2003. applications: CWDM wavelength grid, December 2003.
[G.Sup43] ITU-T Series G Supplement 43, Transport of IEEE 10G base-R [G.Sup43] ITU-T Series G Supplement 43, Transport of IEEE 10G base-R
in optical transport networks (OTN), November 2006. 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.
[RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE
Extensions in Support of End-to-End Generalized Multi- Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872, Protocol Label Switching (GMPLS) Recovery", RFC 4872,
[ASSOC-Info] Berger, L., Faucheur, F., and A. Narayanan, "Usage of [ASSOC-Info] Berger, L., Faucheur, F., and A. Narayanan, "Usage of
The RSVP Association Object", draft-ietf-ccamp-assoc-info, The RSVP Association Object", draft-ietf-ccamp-assoc-info-
work in progress. 00 (work in progress), October 2010.
[ASSOC-Ext] Zhang, F., Jing, R., "RSVP-TE Extension to Establish [ASSOC-Ext] Zhang, F., Jing, R., "RSVP-TE Extension to Establish
Associated Bidirectional LSP", draft-zhang-mpls-tp-rsvp-te- Associated Bidirectional LSP", draft-zhang-mpls-tp-rsvp-
ext-associated-lsp, work in progress. te-ext-associated-lsp-03 (work in progress), February
2011.
Author's Addresses Author's Addresses
Greg M. Bernstein (editor) Greg M. Bernstein (editor)
Grotto Networking Grotto Networking
Fremont California, USA Fremont California, USA
Phone: (510) 573-2237 Phone: (510) 573-2237
Email: gregb@grotto-networking.com Email: gregb@grotto-networking.com
skipping to change at page 22, line 41 skipping to change at page 15, line 41
claimed to pertain to the implementation or use of the technology claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. such rights.
Copies of Intellectual Property disclosures made to the IETF Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers 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 users of this specification can be obtained from the IETF on-line
repository at http://www.ietf.org/ipr IPR repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org. address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
All IETF Documents and the information contained therein are provided All IETF Documents and the information contained therein are
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 63 change blocks. 
452 lines changed or deleted 195 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/