draft-ietf-ccamp-wson-signaling-06.txt   draft-ietf-ccamp-wson-signaling-07.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: January 2014 Y.Lee Expires: September 2014 Y.Lee
Huawei Huawei
G. Martinelli G. Martinelli
Cisco Cisco
Hiroaki Harai Hiroaki Harai
NICT NICT
July 5, 2013 March 5, 2014
Signaling Extensions for Wavelength Switched Optical Networks Signaling Extensions for Wavelength Switched Optical Networks
draft-ietf-ccamp-wson-signaling-06.txt draft-ietf-ccamp-wson-signaling-07.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 applicable in WSONs
under a number of conditions including: (a) when optional under a number of conditions including: (a) when optional
processing, such as regeneration, must be configured to occur at processing, such as regeneration, must be configured to occur at
specific nodes along a path, (b) where equipment must be configured specific nodes along a path, (b) where equipment must be configured
to accept an optical signal with specific attributes, or (c) where to accept an optical signal with specific attributes, or (c) where
equipment must be configured to output an optical signal with equipment must be configured to output an optical signal with
specific attributes. In addition this memo provides mechanisms to specific attributes. In addition this memo provides mechanisms to
support distributed wavelength assignment with bidirectional LSPs, support distributed wavelength assignment with choice in distributed
and choice in distributed wavelength assignment algorithms. These wavelength assignment algorithms. These extensions build on previous
extensions build on previous work for the control of lambda and work for the control of lambda and G.709 based networks. This
G.709 based networks. document updates [RFC6205] as make it applicable to WSON-LSC capable
equipment.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the 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.
skipping to change at page 1, line 48 skipping to change at page 2, line 4
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 Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference 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 January 5, 2007. This Internet-Draft will expire on September 5, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 2, line 37 skipping to change at page 2, line 40
"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 WSON LSPs..................................5 3.3. Bidirectional WSON LSPs...................................6
3.4. Distributed Wavelength Assignment Selection Method........6 3.4. Distributed Wavelength Assignment Selection Method........6
3.5. Out of Scope..............................................6 3.5. Optical Impairments.......................................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..........7 4.1. Traffic Parameters for Optical Tributary Signals..........7
4.2. WSON Processing Object Encoding...........................7 4.2. WSON Processing HOP Attribute TLV Encoding................7
4.3. Signal Attributes and Processing Capabilities.............8 4.3. Signal Attributes and Processing Capabilities.............8
4.4. Wavelength Assignment Method Selection....................8 4.4. Wavelength Assignment Method Selection TLV Encoding.......9
5. Bidirectional Lightpath Setup.................................10
6. Security Considerations.......................................10 5. Security Considerations.......................................10
7. IANA Considerations...........................................11 6. IANA Considerations...........................................10
8. Acknowledgments...............................................11 7. Acknowledgments...............................................11
9. References....................................................12 8. References....................................................12
9.1. Normative References.....................................12 8.1. Normative References.....................................12
9.2. Informative References...................................13 8.2. Informative References...................................13
Author's Addresses...............................................15 Author's Addresses...............................................15
Intellectual Property Statement..................................16 Intellectual Property Statement..................................16
Disclaimer of Validity...........................................17 Disclaimer of Validity...........................................17
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 simultaneous bidirectional wavelength assignment while more advanced
advanced extensions are given to support the networks described in extensions are given to support the networks described in [RFC6163]
[RFC6163] which feature connections requiring configuration of which feature connections requiring configuration of input, output,
input, output, and general signal processing capabilities at a node and general signal processing capabilities at a node along a LSP.
along a LSP.
These extensions build on previous work for the control of lambda These extensions build on previous work for the control of lambda
and G.709 based networks. and G.709 based networks [RFC3471].
Related references with this document are [WSON-info] that provides
a high-level information model and and [WSON-Encode] that provides
common encodings that can be applicable to other protocol extensions
such as routing.
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 35 skipping to change at page 4, line 44
data transmission. 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 needs to convey sufficient information characterizing
signal to allow systems along the path to determine compatibility the signal to allow systems along the path to determine
and perform any required local configuration. Examples of such compatibility and perform any required local configuration. Examples
systems include intermediate nodes (ROADMs, OXCs, Wavelength of such systems include intermediate nodes (ROADMs, OXCs, Wavelength
converters, Regenerators, OEO Switches, etc...), links (WDM systems) converters, Regenerators, OEO Switches, etc...), links (WDM systems)
and end systems (detectors, demodulators, etc...). The details of and end systems (detectors, demodulators, etc...). The details of
any local configuration processes are out of the scope of this any local configuration processes are out of the scope of this
document. 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
skipping to change at page 5, line 40 skipping to change at page 6, line 5
(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 The extensions here MUST provide for the configuration of these
types of processing at nodes along an LSP. types of processing at nodes along an LSP.
3.3. Bi-Directional WSON LSPs 3.3. Bidirectional WSON LSPs
WSON signaling MAY support LSP setup consistent with the wavelength WSON signaling can support LSP setup consistent with the wavelength
continuity constraint for bi-directional connections. The following continuity constraint for bidirectional connections. The following
cases MAY be separately supported: cases need to be separately supported:
(a) Where the same wavelength is used for both upstream and (a) Where the same wavelength is used for both upstream and
downstream 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.
This document will review current GMPLS bidirectional solutions This document will review current GMPLS bidirectional solutions
according to WSON case. according to WSON case.
3.4. Distributed Wavelength Assignment Selection Method 3.4. Distributed Wavelength Assignment Selection Method
WSON signaling MAY support the selection of a specific distributed WSON signaling can support the selection of a specific distributed
wavelength assignment method. wavelength assignment method.
This method is beneficial in cases of equipment failure, etc., where This method is beneficial in cases of equipment failure, etc., where
fast provisioning used in quick recovery is critical to protect fast provisioning used in quick recovery is critical to protect
carriers/users against system loss. This requires efficient carriers/users against system loss. This requires efficient
signaling which supports distributed wavelength assignment, in signaling which supports distributed wavelength assignment, in
particular when the centralized wavelength assignment capability is particular when the centralized wavelength assignment capability is
not available. not available.
As discussed in the [RFC6163] different computational approaches for As discussed in the [RFC6163] different computational approaches for
wavelength assignment are available. One method is the use of wavelength assignment are available. One method is the use of
distributed wavelength assignment. This feature would allow the distributed wavelength assignment. This feature would allow the
specification of a particular approach when more than one is specification of a particular approach when more than one is
implemented in the systems along the path. implemented in the systems along the path.
3.5. Out of Scope 3.5. Optical Impairments
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 compatibility amongst various networks devices and end systems it
can 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].
LSPs signaled through extensions provided in this document MUST
apply the following signaling parameters:
. Switching Capability = WSON-LSC ([WSON-OSPF]).
. Encoding Type = Lambda ([RFC3471])
. Label Format = as defined in [RFC6205]
[RFC6205] defines the label format as applicable to LSC capable
device. This document extend [RFC6205] as make its label format
applicable also to WSON-LSC capable devices.
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 (byte rate) of the signals are defined as parameters and in
[RFC3473] they are conveyed Generalized Label Request object and the [RFC3473] they are conveyed Generalized Label Request object and the
RSVP SENDER_TSPEC/FLOWSPEC objects respectively. RSVP SENDER_TSPEC/FLOWSPEC objects respectively.
4.2. WSON Processing Object Encoding 4.2. WSON Processing HOP Attribute TLV Encoding
Section 3.2. provided the requirements for signaling to indicate to Section 3.2. provided the requirements for signaling to indicate to
a particular NE along an LSP what type of processing to perform on 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 or how to configure that NE to accept or transmit
an optical signal with particular attributes. an optical signal with particular attributes.
To target a specific node, this section defines a WSON_Processing To target a specific node, this section defines a WSON_Processing
object as part of the LSP_REQUIRED_ATTRIBUTE and follows procedures object as part of the LSP_REQUIRED_ATTRIBUTE and follows procedures
defined in [RSVP-RO]. defined in [RSVP-RO].
The content of this object is defined in the subsequent sections. The content of this TLV is defined in the subsequent sections. (See
(See Section 4.3 for <RBInformation> TLV and Section 4.4 for Section 4.3 for <RBInformation> TLV and Section 4.4 for
<WavelengthSelection> TLV, respectively.) <WavelengthSelection> TLV, respectively.)
<WSON_Processing> ::= <RBInformation> [<RBInformation>] <WSON_Processing HOP Attribute> ::= <RBInformation>
[<WavelengthSelection>] [<RBInformation>]
The WSON Processing object encoding is defined as:
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: to be defined by IANA
Value: sub-TLVS according to section 4.3 and 4.4 The WSON Processing carries sub-TLVs of the same format as a HOP
Attributes TLV, as defined in [RSVP-RO].
4.3. Signal Attributes and Processing Capabilities 4.3. Signal Attributes and Processing Capabilities
The [WSON-Encode] already provides all necessary definitions and The [WSON-Encode] already provides all necessary definitions and
encoding for WSON information required for signaling. In particular, encoding for WSON information required for signaling. In particular,
the Resource block information sub-TLV contains, among others, a the Resource block information sub-TLV contains, among others, a
list of available Optical Interface Classes and processing list of available Optical Interface Classes and processing
capabilities. capabilities.
<RBInformation> is defined in Section 4.1 of [WSON-Encode]. <RBInformation> is defined in Section 4.1 of [WSON-Encode].
Type Sub-TLV Type Sub-TLV
1 (TBA) <RBInformation> 1 (TBA) <RBInformation>
At least one <RBInformation> sub-TLV MUST always be present in the At least one <RBInformation> sub-TLV MUST always be present in the
WSON_Processing Object otherwise a PathErr SHALL be generated. At WSON_Processing HOP Attribute TLV.. At most two <RBInformation> sub-
most two <RBInformation> sub-TLVs MAY be present in the TLVs MAY be present in the WSON_Processing HOP Attribute TLV . If
WSON_Processing Object. If more than two objects are encountered, more than two objects are encountered, two MUST be processed and the
two MUST be processed and the rest SHOULD be ignored. rest SHOULD be ignored.
The <RBInformation> contains several information as defined by The <RBInformation> contains several information as defined by
[WSON-Encode]. The following processing rules apply: [WSON-Encode]. The following processing rules apply:
RB Set Field MAY contain more than one RB Indetifier. Only the first RB Set Field MAY contain more than one RB Indetifier. Only the first
one MUST be processed, the others SHOULD be ignored. one MUST be processed, the others SHOULD be ignored.
The I an E flags MUST be set according to bidirectional LSP The I an E flags MUST be set according to bidirectional LSP
signaling and the numbers of RBInformation subobjects available. In signaling and the numbers of RBInformation subobjects available. In
case of unidirectional signaling, only one RBInformartion sub-object case of unidirectional signaling, only one RBInformartion sub-object
MUST be processed and I/E bits can be safely ignored. In case of MUST be processed and I/E bits can be safely ignored. In case of
bidirectional signaling: if only one RBInformartion is available, bidirectional signaling: if only one RBInformartion is available,
bits I and E MUST be both set to 1, if two RBInformation sub-objects bits I and E MUST be both set to 1, if two RBInformation sub-objects
are available, bits I and E MUST have different values. are available, bits I and E MUST have different values.
The rest of information available within RBInformation sub-object is The rest of information available within RBInformation sub-object is
Optical Interface Class List, Input Bit Range List and Processing Optical Interface Class List, Input Bit Range List and Processing
Capability List. Lists MAY contain one or more elements. Capability List. Lists MAY contain one or more elements. The usage
of WSON Processing object for the bidirectional case is the same as
per unidirectional. When an intermediate node uses information from
this object to instruct a node about wavelength regeneration, the
same information applies to both downstream and upstream directions.
4.4. Wavelength Assignment Method Selection 4.4. Wavelength Assignment Method Selection TLV Encoding
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 function will be a path but the wavelength will be selected on a
hop-by-hop basis. hop-by-hop basis.
Under this hypothesis the node initiating the signaling process Under this hypothesis the node initiating the signaling process
needs to declare its own wavelength availability (through a needs to declare its own wavelength availability (through a
label_set object). Each intermediate node may delete some labels due label_set object). Each intermediate node may delete some labels due
to connectivity constraints or its own assignment policy. At the to connectivity constraints or its own assignment policy. At the
skipping to change at page 9, line 22 skipping to change at page 9, line 27
wavelength assignment among the ones received through the signaling wavelength assignment among the ones received through the signaling
process. process.
As discussed in [HZang00] a number of different wavelength As discussed in [HZang00] a number of different wavelength
assignment algorithms maybe employed. In addition as discussed in assignment algorithms maybe employed. In addition as discussed in
[RFC6163] the wavelength assignment can be either for a [RFC6163] the wavelength assignment can be either for a
unidirectional lightpath or for a bidirectional lightpath unidirectional lightpath or for a bidirectional lightpath
constrained to use the same lambda in both directions. constrained to use the same lambda in both directions.
A simple sub-TLV could be used to indication wavelength assignment A simple sub-TLV could be used to indication wavelength assignment
directionality and wavelength assignment method. directionality and wavelength assignment method as a TLV in the LSP
Attributes Object, as defined in [RFC5420].
Type Sub-TLV Type Sub-TLV
2 <WavelengthSelection> TDB <WavelengthSelection>
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|W| WA Method | Reserved | |W| WA Method | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where: Where:
. W is a bit, 0 same wavelength in both directions, 1 may use . W is a bit, 0 same wavelength in both directions, 1 may use
different wavelengths different wavelengths
. Wavelength Assignment (WA) Method: 0 unspecified (any), 1 . Wavelength Assignment (WA) Method: 0 unspecified (any), 1
First-Fit, 2 Random, 3 Least-Loaded (multi-fiber). Others TBD. First-Fit, 2 Random, 3 Least-Loaded (multi-fiber). Others TBD.
This sub-TLV MAY be present in the WSON_Processing Object. If more 5. Security Considerations
than one sub-TLV is encountered the first one MUST be processed, the
rest SHOULD be ignored.
5. Bidirectional Lightpath Setup
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. In addition to the wavelength
continuity constraint, requirement 3.3 gives us another constraint
on wavelength usage in data plane, in particular, it requires the
same wavelength to be used in both directions. [RFC6163] in section
6.1 reports on the implication to GMPLS signaling related to both
bi-directionality and Distributed Wavelengths Assignment.
Current GMPLS solution defines a bidirectional LSP (as defined by
[RFC3471]). 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. Since this mechanism is currently
available and proven to work, no additional extensions are needed
for WSON. Potential optimizations are left for further studies.
The usage of WSON Processing object for the bidirectional case is
the same as per unidirectional. When an intermediate node uses
information from this object to instruct a node about wavelength
regeneration, the same information applies to both downstream and
upstream directions.
Some implementations may prefer using 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.
6. 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 This document is builds on the mechanisms defined in [RFC3473], and
protocols may significantly affect the loading of those protocols. only differs in specific information communicated. As such, this
This makes the operation of the network more vulnerable to denial of document introduces no new security considerations to the existing
service attacks. Therefore additional care maybe required to ensure GMPLS signaling protocols. See [RFC3473], for details of the
that the protocols are secure in the WSON environment. supported security measures. Additionally, [RFC5920] provides an
overview of security vulnerabilities and protection mechanisms for
the GMPLS control plane.
Furthermore the additional information distributed in order to 6. IANA Considerations
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.
7. IANA Considerations Upon approval of this document, IANA will make the following
assignments as follows:
A new LSP_REQUIRED_ATTRIBUTE type is required A new LSP_REQUIRED_ATTRIBUTE type is required
TBA: WSON Processing Object (Section 4.2) Value Sub-TLV Reference
Two types of sub-TLV are allowed within the WSON Processing Object 3 (Suggested) WSON Processing HOP Attribute TLV [This ID]
Value Sub-TLV One new type sub-TLV is allowed within the LSP_Attributes Object
1 (Proposed) WSON Processing Capabilities (Section 4.3) Value Sub-TLV Reference
2 (Proposed) WSON Wavelength Assignments (Section 4.4) 4 (Suggested) Wavelength Selection [This ID]
8. Acknowledgments 7. Acknowledgments
Authors would like to thanks Lou Berger and Cyril Margaria for Authors would like to thanks Lou Berger and Cyril Margaria for
comments and suggestions. comments and suggestions.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)", "Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999. STD 58, RFC 2578, April 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
skipping to change at page 12, line 38 skipping to change at page 12, line 38
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
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.
[WSON-Encode] Bernstein G., Lee Y., Li D., and W. Imajuku, "Routing [RFC5920] Luyuan Fang(Ed.), "Security Framework for MPLS and GMPLS
and Wavelength Assignment Information Encoding for Networks", RFC5920, July 2010. [WSON-Encode] Bernstein
Wavelength Switched Optical Networks", draft-ietf-ccamp- G., Lee Y., Li D., and W. Imajuku, "Routing and Wavelength
rwa-wson-encode-20 (work in progress). Assignment Information Encoding for Wavelength Switched
Optical Networks", draft-ietf-ccamp-rwa-wson-encode, work
in progress.
[RFC6205] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized
Labels for G.694 Lambda-Switching Capable Label Switching
Routers", RFC 6205, March 2011.
[RSVP-RO] Margaria, C., et al, "LSP Attribute in ERO", draft-ietf- [RSVP-RO] Margaria, C., et al, "LSP Attribute in ERO", draft-ietf-
ccamp-lsp-attribute-ro (work in progress). ccamp-lsp-attribute-ro,work in progress.
9.2. Informative References 8.2. Informative References
[WSON-CompOSPF] Y. Lee, G. Bernstein, "OSPF Enhancement for Signal [WSON-CompOSPF] Y. Lee, G. Bernstein, "OSPF Enhancement for Signal
and Network Element Compatibility for Wavelength Switched and Network Element Compatibility for Wavelength Switched
Optical Networks", work in progress: draft-lee-ccamp-wson- Optical Networks", work in progress: draft-lee-ccamp-wson-
signal-compatibility-OSPF. signal-compatibility-OSPF.
[RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS
and PCE Control of Wavelength Switched Optical Networks", and PCE Control of Wavelength Switched Optical Networks",
work in progress: draft-bernstein-ccamp-wavelength- work in progress: draft-bernstein-ccamp-wavelength-
switched-03.txt, February 2008. switched-03.txt, February 2008.
[WSON-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and [WSON-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and
Wavelength Assignment Information Model for Wavelength Wavelength Assignment Information Model for Wavelength
Switched Optical Networks", work in progress: draft-ietf- Switched Optical Networks", work in progress: draft-ietf-
ccamp-rwa-info-18. ccamp-rwa-info, work in progress.
[HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing
and 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.
[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.
skipping to change at page 14, line 9 skipping to change at page 15, line 5
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery [RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized (Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, March Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
2006. 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
The RSVP Association Object", draft-ietf-ccamp-assoc-info-
00 (work in progress), October 2010.
[ASSOC-Ext] Zhang, F., Jing, R., "RSVP-TE Extension to Establish
Associated Bidirectional LSP", draft-zhang-mpls-tp-rsvp-
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
Nicola Andriolli Nicola Andriolli
 End of changes. 47 change blocks. 
143 lines changed or deleted 106 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/