draft-ietf-ccamp-wson-signaling-08.txt   draft-ietf-ccamp-wson-signaling-09.txt 
Network Working Group G. Bernstein Network Working Group G. Bernstein
Internet Draft Grotto Networking Internet Draft Grotto Networking
Updates: 6205 Sugang Xu Updates: 6205 Sugang Xu
Intended status: Standards Track NICT Intended status: Standards Track NICT
Y.Lee Y.Lee
Huawei Huawei
Expires: November 2015 G. Martinelli Expires: March 2015 G. Martinelli
Cisco Cisco
Hiroaki Harai Hiroaki Harai
NICT NICT
July 3, 2014 September 12, 2014
Signaling Extensions for Wavelength Switched Optical Networks Signaling Extensions for Wavelength Switched Optical Networks
draft-ietf-ccamp-wson-signaling-08.txt draft-ietf-ccamp-wson-signaling-09.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 applicable 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
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 3, 2007. This Internet-Draft will expire on March 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
warranty as 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
document are to be interpreted as described in [RFC2119]. this 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 Node Processing Configuration.........................5 3.2. Per Node Processing Configuration.........................5
3.3. Bidirectional WSON LSPs...................................6 3.3. Bidirectional WSON LSPs...................................6
3.4. Distributed Wavelength Assignment Selection Method........6 3.4. Distributed Wavelength Assignment Selection Method........6
3.5. Optical Impairments.......................................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 HOP Attribute TLV Encoding................7 4.2. WSON Processing HOP Attribute TLV.........................7
4.3. Resource Block Information Sub-TLV........................8 4.2.1. Resource Block Information Sub-TLV......................8
4.4. Wavelength Selection Sub-TLV..............................9 4.2.2. Wavelength Selection Sub-TLV............................9
5. Security Considerations.......................................11 5. Security Considerations.......................................11
6. IANA Considerations...........................................12 6. IANA Considerations...........................................12
7. Acknowledgments...............................................13 7. Acknowledgments...............................................13
8. References....................................................14 8. References....................................................14
8.1. Normative References.....................................14 8.1. Normative References.....................................14
8.2. Informative References...................................15 8.2. Informative References...................................15
Author's Addresses...............................................16 Author's Addresses...............................................15
Intellectual Property Statement..................................17
Disclaimer of Validity...........................................18
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 bidirectional wavelength assignment while more advanced simultaneous bidirectional wavelength assignment while more advanced
extensions are given to support the networks described in [RFC6163] extensions are given to support the networks described in [RFC6163]
which feature connections requiring configuration of input, output, which feature connections requiring configuration of input, output,
and general signal processing capabilities at a node along a Label and general signal processing capabilities at a node along a Label
skipping to change at page 5, line 33 skipping to change at page 5, line 33
signaling along with the ability to share client signal type signaling along with the ability to share client signal type
information (G-PID). In addition, bit rate is a standard GMPLS information (G-PID). In addition, bit rate is a standard GMPLS
signaling traffic parameter. It is referred to as Bandwidth Encoding signaling traffic parameter. It is referred to as Bandwidth Encoding
in [RFC3471]. in [RFC3471].
3.2. Per Node Processing Configuration 3.2. Per Node Processing Configuration
In addition to configuring a node along an LSP to input or output a In addition to configuring a node along an LSP to input or output a
signal with specific attributes, we may need to signal the node to signal with specific attributes, we may need to signal the node to
perform specific processing, such as 3R regeneration, on the signal perform specific processing, such as 3R regeneration, on the signal
at a particular NE. [RFC6163] discussed three types of processing: at a particular node. [RFC6163] discussed three types of
processing:
(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 provide for the configuration of these types of The extensions here provide for the configuration of these types of
processing at nodes along an LSP. processing at nodes along an LSP.
skipping to change at page 7, line 23 skipping to change at page 7, line 23
device. This document extends [RFC6205] as make its label format device. This document extends [RFC6205] as make its label format
applicable also to WSON-LSC capable devices. 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 HOP Attribute TLV Encoding 4.2. WSON Processing HOP Attribute TLV
Section 3.2. provided the requirements for signaling to indicate to Section 3.2. provided the requirements for signaling to indicate to
a particular node along an LSP what type of processing to perform on a particular node along an LSP what type of processing to perform on
an optical signal or how to configure that node to accept or an optical signal or how to configure that node to accept or
transmit an optical signal with particular attributes. transmit 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
HOP Attribute TLV, which is carried in the subobjects defined in HOP Attribute TLV. This TLV is encoded as an attributes TLV, see
[RSVP-RO]. The Type value of the WSON Processing HOP Attribute TLV [RFC5420]. The TLV is carried in the ERO and RRO LSP Attribute
Subobjects, and processed according to the procedures, defined in
[RSVP-RO]. The type value of the WSON Processing HOP Attribute TLV
is TBD by IANA. is TBD by IANA.
The contents of this TLV is defined in the subsequent sections. The WSON Processing HOP Attribute TLV carries one or more sub-TLVs
Section 4.3 for ResourceBlockInfo sub-TLV and Section 4.4 for with the following format:
WavelengthSelection sub-TLV, respectively. The TLV can be
represented in Reduced Backus-Naur Form (RBNF) [RFC5511] syntax as:
<WSON Processing HOP Attribute> ::= < ResourceBlockInfo> 0 1 2 3
[<ResourceBlockInfo>] <WavelengthSelection> 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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The WSON Processing HOP Attribute TLV is a type of a HOP Attributes Type
TLV, as defined in [RSVP-RO]. If a receiving node does not recognize
a sub-TLV, it will follow the procedure defined in [RFC5420], i.e.,
it MUST generate a PathErr with a new error value of the existing
Error Code "Unknown Attributes TLV (Sub-codes - 29)".
4.3. Resource Block Information Sub-TLV The identifier of the sub-TLV.
The Resource block information , or ResourceBlockInfo, sub-TLV Length
contains a list of available Optical Interface Classes and
processing capabilities.
The format of the ResourceBlockInfo sub-TLV value field is defined Indicates the total length of the sub-TLV in octets. That is,
in Section 4 of [WSON-Encode]. the combined length of the Type, Length, and Value fields,
i.e., four plus the length of the Value field in octets.
Type Sub-TLV Name The entire sub-TLV MUST be padded with zeros to ensure four-
octet alignment of the sub-TLV. The Length field does not
include any padding.
1 (TBA) ResourceBlockInfo Value
Zero or more octets of data carried in the sub-TLV.
Sub-TLV ordering is significant and MUST be preserved. Error
processing follows [RSVP-RO].
The following sub-TLV types are defined in this document:
Sub-TLV Name Type Length
--------------------------------------------------------------
ResourceBlockInfo 1 variable
WavelengthSelection 2 1 (3 octets padding)
The TLV can be represented in Reduced Backus-Naur Form (RBNF)
[RFC5511] syntax as:
<WSON Processing HOP Attribute> ::= <ResourceBlockInfo>
[<ResourceBlockInfo>] [<WavelengthSelection>]
4.2.1. ResourceBlockInfo Sub-TLV
The format of the ResourceBlockInfo sub-TLV value field is defined
in Section 4 of [WSON-Encode]. It is a list of available Optical
Interface Classes and processing capabilities.
At least one ResourceBlockInfo sub-TLV MUST be present in the At least one ResourceBlockInfo sub-TLV MUST be present in the
WSON_Processing HOP Attribute TLV. At most two ResourceBlockInfo WSON_Processing HOP Attribute TLV. No more than two
sub-TLVs MAY be present in the WSON_Processing HOP Attribute TLV. If ResourceBlockInfo sub-TLVs SHOULD be present. Any present
more than two sub-TLVs are encountered, the first two MUST be ResourceBlockInfo sub-TLVs MUST be processed in the order received,
processed and the rest SHOULD be ignored. and extra (unprocessed) SHOULD be ignored.
The <ResourceBlockInfo> contains several information as defined by The ResourceBlockInfo field contains several information elements as
[WSON-Encode]. The following processing rules apply to the sub-TLV: defined by [WSON-Encode]. The following rules apply to the sub-TLV:
RB Set Field MAY contain more than one RB Identifier. Only the first o RB Set Field can carry one or more RB Identifier. Only the first
of which MUST be processed, the others SHOULD be ignored. of RB Identifier listed in the RB Set Field SHALL be processed,
any others SHOULD be ignored.
In case of signalin a unidirectional LSP, only one ResourceBlockInfo o In the case of unidirectional LSPs, only one ResourceBlockInfo
sub-TLV MUST be processed and I/O bits can be safely ignored. sub-TLV SHALL be processed and the I and O bits can be safely
ignored.
In case of signaling a bidirectional LSP: if only one o In the case of a bidirectional LSP, there MUST be either:
ResourceBlockInfo is included, bits I and O MUST be both set to 1, (a) only one ResourceBlockInfo sub-TLV present in a
if two ResourceBlockInfo sub-TLVs are included, bits I and O MUST WSON_Processing HOP Attribute TLV, and the bits I and O both
have different values, i.e., only one bit can be set in each set to 1, or
ResourceBlockInfo sub-TLV. Any violation of these detected by a (b) two ResourceBlockInfo sub-TLVs present, one of which has only
transit or egress node will incur a processing error and SHOULD NOT the I bit set and the other of which has only the O bit set.
trigger any RSVP message but can be logged locally, and perhaps
reported through network management mechanisms.
The rest of information available within ResourceBlockInfo sub-TLV o The rest of information carried within the ResourceBlockInfo
is Optical Interface Class List, Input Bit Rate List and Processing sub-TLV includes Optical Interface Class List, Input Bit Rate
Capability List. These lists MAY contain one or more elements. The List and Processing Capability List. These lists MAY contain one
usage of WSON Processing HOP Attribute TLV for the bidirectional or more elements. These elements apply equally to both
case is the same as per unidirectional. When an intermediate node bidirectional and unidirectional LSPs.
uses information from this TLV to instruct a node about wavelength
regeneration, the same information applies to both downstream and
upstream directions.
This sub-TLV is constructed by an ingress node and the processing is Any violation of these rules detected by a transit or egress node
applied to all nodes (transit and egress) whose R bit is set in the SHALL be treated as an error and be processed per [RSVP-RO].
ERO HOP ATTRIBUTE subobject according to [RSVP-RO]. When the R bit
is set, a node MUST examine the ResourceBlockInfo sub-TLV present in
the subobject following the rule described in [RFC5420].
If a node processing an ERO HOP ATTRIBUTE subobject with WSON A ResourceBlockInfo sub-TLV can be constructed by a node and added
Processing HOP Attributes TLV (which may include the to a ERO_HOP_ATTRIBUTE subobject in order to be processed by
ResourceBlockInfo sub-TLVs) longer than the ERO subobject SHOULD downstream nodes (transit and egress). As defined in [RSVP-RO], the
return a PathErr with an error code "Routing Error" and error value R bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE semantic
"Bad EXPLICT_ROUTE object" with the EXPLICIT_ROUTE object included defined in [RFC5420] and SHOULD be set accordingly.
as defined in [RSVP-RO] Section 3.3.
Once a node properly parsed the Sub-TLV, the node applies the Once a node properly parses a ResourceBlockInfo Sub-TLV received in
selected regeneration pool (at that hop) for the LSP. In addition, an ERO_HOP_ATTRIBUTE subobject (according to the rules stated above
the node SHOULD report compliance by adding a RRO_HOP_ATTRIBUTE and in [RSVP-RO]), the node allocates the indicated resources, e.g.,
subobject with the WSON Processing HOP Attribute TLV (and its sub- the selected regeneration pool, for the LSP. In addition, the node
TLVs) which describes the attributes to be reported. SHOULD report compliance by adding a RRO_HOP_ATTRIBUTE subobject
with the WSON Processing HOP Attribute TLV (and its sub-
TLVs) indicating the utilized resources. ResourceBlockInfo Sub-TLVs
carried in a RRO_HOP_ATTRIBUTE subobject are subject to [RSVP-RO]
and standard RRO processing, see [RFC3209].
4.4. Wavelength Selection Sub-TLV 4.2.2. WavelengthSelection Sub-TLV
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
needs to declare its own wavelength availability (through a
label_set object). Each intermediate node may delete some labels due
to connectivity constraints or its own assignment policy. At the
end, the destination node has to make the final decision on the
wavelength assignment among the ones received through the signaling
process.
As discussed in [HZang00], a number of different wavelength As discussed in [HZang00], a number of different wavelength
assignment algorithms may be employed. In addition as discussed in assignment algorithms may be 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.
In order to indicate wavelength assignment directionality and In order to indicate wavelength assignment directionality and
wavelength assignment method, a new Wavelength Selection, or wavelength assignment method, the Wavelength Selection, or
WavelengthSelection, sub-TLV is defined to be carried in the WSON WavelengthSelection, sub-TLV is defined to be carried in the WSON
Processing HOP Attribute TLV defined in Section 4.2 of this draft. Processing HOP Attribute TLV defined above.
The type value of the Sub-TLV is:
Type Sub-TLV Name
2(TDA) <WavelengthSelection>
The WavlengthSelection sub-TLV value field is defined as: The WavlengthSelection sub-TLV value field is defined as:
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 (1 bit): 0 denotes requiring the same wavelength in both W (1 bit): 0 denotes requiring the same wavelength in both
directions, 1 denotes that different wavelengths on both directions directions, 1 denotes that different wavelengths on both directions
are allowed. are allowed.
Wavelength Assignment (WA) Method (7 bits): Wavelength Assignment (WA) Method (7 bits):
0 - unspecified (any); This does not constrain the WA method used by 0 - unspecified (any); This does not constrain the WA method used by
a specific node. a specific node. This value is implied when the WavelengthSelection
Sub-TLV is absent.
1 - First-Fit. All the wavelengths are numbered and this WA method 1 - First-Fit. All the wavelengths are numbered and this WA method
chooses the available wavelength with the lowest index. chooses the available wavelength with the lowest index.
2 - Random. This WA method chooses an available wavelength randomly. 2 - Random. This WA method chooses an available wavelength randomly.
3 - Least-Loaded (multi-fiber). This WA method selects the 3 - Least-Loaded (multi-fiber). This WA method selects the
wavelength that has the largest residual capacity on the most loaded wavelength that has the largest residual capacity on the most loaded
link along the route. This method is used in multi-fiber networks. link along the route. This method is used in multi-fiber networks.
If used in single-fiber networks, it is equivalent to the FF WA If used in single-fiber networks, it is equivalent to the FF WA
skipping to change at page 11, line 11 skipping to change at page 11, line 11
If a receiving node does not support the attribute(s), its behaviors If a receiving node does not support the attribute(s), its behaviors
are specified below: are specified below:
- W bit not supported: a PathErr MUST be generated with the Error - W bit not supported: a PathErr MUST be generated with the Error
Code "Routing Problem" (24) with error sub-code "Unsupported Code "Routing Problem" (24) with error sub-code "Unsupported
WavelengthSelection Symmetry value" (value to be assigned by IANA, WavelengthSelection Symmetry value" (value to be assigned by IANA,
suggested value: 107). suggested value: 107).
- WA method not supported: a PathErr MUST be generated with the - WA method not supported: a PathErr MUST be generated with the
Error Code "Routing Problem" (24) with error sub-code "unsupported Error Code "Routing Problem" (24) with error sub-code "Unsupported
Wavelength Assignment value" (value to be assigned by IANA, Wavelength Assignment value" (value to be assigned by IANA,
suggested value: 108). suggested value: 108).
This sub-TLV is constructed by an ingress node and the processing is A WavelengthSelection sub-TLV can be constructed by a node and added
applied to all nodes (transit and egress) whose R bit is set in the to a ERO_HOP_ATTRIBUTE subobject in order to be processed by
ERO HOP ATTRIBUTE subobject according to [RSVP-RO]. When the R bit downstream nodes (transit and egress). As defined in [RSVP-RO], the
is set, a node MUST examine the WavelengthSelection sub-TLV present R bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE semantic
in the subobject following the rule described in [RFC5420]. defined in [RFC5420] and SHOULD be set accordingly.
If a node processing an ERO HOP ATTRIBUTE subobject with WSON
Processing HOP Attributes TLV (which may include the
WavelengthSelection sub-TLVs) longer than the ERO subobject SHOULD
return a PathErr with an error code "Routing Error" and error value
"Bad EXPLICT_ROUTE object" with the EXPLICIT_ROUTE object included
as defined in [RSVP-RO] Section 3.3.
Once a node properly parsed the Sub-TLV, the node applies wavelength Once a node properly parses the WavelengthSelection Sub-TLV received
assignment method (at that hop) for the LSP. In addition, the node in an ERO_HOP_ATTRIBUTE subobject, the node use the indicated
SHOULD report compliance by adding a RRO_HOP_ATTRIBUTE subobject wavelength assignment method (at that hop) for the LSP. In addition,
with the WSON Processing HOP Attribute TLV (and its sub-TLVs) which the node SHOULD report compliance by adding a RRO_HOP_ATTRIBUTE
describes the attributes to be reported. subobject with the WSON Processing HOP Attribute TLV (and its
sub-TLVs) indicated the utilized method. WavelengthSelection
Sub-TLVs carried in a RRO_HOP_ATTRIBUTE subobject are subject to
[RSVP-RO] and standard RRO processing, see [RFC3209].
5. Security Considerations 5. Security Considerations
This document is builds on the mechanisms defined in [RFC3473], and This document is built on the mechanisms defined in [RFC3473], and
only differs in specific information communicated. As such, this only differs in specific information communicated. As such, this
document introduces no new security considerations to the existing document introduces no new security considerations to the existing
GMPLS signaling protocols. See [RFC3473], for details of the GMPLS signaling protocols. See [RFC3473], for details of the
supported security measures. Additionally, [RFC5920] provides an supported security measures. Additionally, [RFC5920] provides an
overview of security vulnerabilities and protection mechanisms for overview of security vulnerabilities and protection mechanisms for
the GMPLS control plane. the GMPLS control plane.
6. IANA Considerations 6. IANA Considerations
Upon approval of this document, IANA is requested to make the Upon approval of this document, IANA is requested to make the
assignment of a new value for the existing "Attributes TLV Space" assignment of a new value for the existing "Attributes TLV Space"
registry located at http://www.iana.org/assignments/rsvp-te- registry located at http://www.iana.org/assignments/rsvp-te-
parameters/rsvp-te-parameters.xhtml: parameters/rsvp-te-parameters.xhtml, as updated by [RSVP-RO]:
Type Name Allowed on Allowed on Reference Type Name Allowed on Allowed on Allowed on Reference
LSP ATTRIBUTES LSP REQUIRED_ LSP LSP REQUIRED RO LSP
ATTRIBUTES ATTRIBUTES ATTRIBUTES Attribute
Subobject
4 (Suggested) WSON No No [This.I-D] TBA WSON No No Yes [This.I-D]
Processing Processing
HOP Attribute HOP
TLV Attribute
TLV
Upon approval of this document, IANA is requested to create a new Upon approval of this document, IANA is requested to create a new
registry named "Sub-TLV Types for WSON Processing HOP Attribute TLV" registry named "Sub-TLV Types for WSON Processing HOP Attribute TLV"
located at http://www.iana.org/assignments/rsvp-te-parameters/rsvp- located at http://www.iana.org/assignments/rsvp-te-parameters/rsvp-
te-parameters.xhtml. te-parameters.xhtml.
The following entries are to be added: The following entries are to be added:
Value Length Sub-TLV Type Reference Value Sub-TLV Type Reference
1 (suggested) variable ResourceBlockInfo [This.I-D] 1 ResourceBlockInfo [This.I-D]
2 (Suggested) 4 WavelengthSelection [This.I-D] 2 WavelengthSelection [This.I-D]
All assignments are to be performed via Standards Action as defined All assignments are to be performed via Standards Action and
in [RFC5226 <http://tools.ietf.org/html/rfc5226>]. Specification Required policies as defined in [RFC5226
<http://tools.ietf.org/html/rfc5226>].
Upon approval of this document, IANA is requested to create a new Upon approval of this document, IANA is requested to create a new
registry named "Values for Wavelength Assignment Method field in registry named "Values for Wavelength Assignment Method field in
WavelengthSelection Sub-TLV" located at WavelengthSelection Sub-TLV" located at
http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te- http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-
parameters.xhtml. parameters.xhtml.
The following entries are to be added: The following entries are to be added:
Value Meaning Reference Value Meaning Reference
skipping to change at page 13, line 4 skipping to change at page 13, line 6
Upon approval of this document, IANA is requested to create a new Upon approval of this document, IANA is requested to create a new
registry named "Values for Wavelength Assignment Method field in registry named "Values for Wavelength Assignment Method field in
WavelengthSelection Sub-TLV" located at WavelengthSelection Sub-TLV" located at
http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te- http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-
parameters.xhtml. parameters.xhtml.
The following entries are to be added: The following entries are to be added:
Value Meaning Reference Value Meaning Reference
0 unspecified [This.I-D] 0 unspecified [This.I-D]
1 First-Fit [This.I-D] 1 First-Fit [This.I-D]
2 Random [This.I-D] 2 Random [This.I-D]
3 Least-Loaded (multi-fiber) [This.I-D] 3 Least-Loaded (multi-fiber) [This.I-D]
4-127 unassigned 4-127 unassigned
All assignments are to be performed via Standards Action as defined
in [RFC5226 <http://tools.ietf.org/html/rfc5226>].
Upon approval of this document, IANA is requested to make the
assignment of a new value for the existing "Error Codes and
Globally-Defined Error Value Sub-Codes - 29 Unknown Attribute TLV"
registry located at http://www.iana.org/assignments/rsvp-
parameters/rsvp-parameters.xml:
Value Meaning Reference
41 (suggested) Unknown WSON Processing All assignments are to be performed via Standards Action and
HOP Attribute sub-TLV type [This.I-D] Specification Required policies as defined in [RFC5226
<http://tools.ietf.org/html/rfc5226>].
Upon approval of this document, IANA is requested to make the Upon approval of this document, IANA is requested to make the
assignment of a new value for the existing "Sub-Codes . 24 Routing assignment of a new value for the existing "Sub-Codes . 24 Routing
Problem" registry located at http://www.iana.org/assignments/rsvp- Problem" registry located at http://www.iana.org/assignments/rsvp-
parameters/rsvp-parameters.xml: parameters/rsvp-parameters.xml:
Value Description Reference Value Description Reference
107 Unsupported WavelengthSelection 107 Unsupported WavelengthSelection
symmetry value [This.I-D] symmetry value [This.I-D]
108 Unsupported Wavelength Assignment 108 Unsupported Wavelength Assignment
value [This.I-D] value [This.I-D]
7. Acknowledgments 7. Acknowledgments
Authors would like to thanks Lou Berger, Cyril Margaria and Xian Authors would like to thanks Lou Berger, Cyril Margaria and Xian
Zhang for comments and suggestions. Zhang for comments and suggestions.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 14, line 30 skipping to change at page 14, line 30
[WSON-OSPF] Lee, Y, Bernstein G., "GMPLS OSPF Enhancement for Signal [WSON-OSPF] Lee, Y, Bernstein G., "GMPLS OSPF Enhancement for Signal
and Network Element Compatibility for Wavelength Switched and Network Element Compatibility for Wavelength Switched
Optical Networks", draft-ietf-ccamp-wson-signal- Optical Networks", draft-ietf-ccamp-wson-signal-
compatibility-ospf, work in progress. compatibility-ospf, work in progress.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009. Specifications", RFC 5511, April 2009.
[RFC3209] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471, (GMPLS) Signaling Functional Description", RFC 3471,
January 2003. January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol- Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003. January 2003.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A.
skipping to change at page 17, line 4 skipping to change at page 16, line 26
P.R.China P.R.China
Email: jyf@bupt.edu.cn Email: jyf@bupt.edu.cn
Daniel King Daniel King
Old Dog Consulting Old Dog Consulting
Email: daniel@olddog.co.uk Email: daniel@olddog.co.uk
Young Lee (editor) Young Lee (editor)
Huawei Technologies Huawei Technologies
5360 Legacy Dr. Building 3 5340 Legacy Dr. Building 3
Plano, TX 75024 Plano, TX 75024
USA USA
Phone: (469) 277-5838 Phone: (469) 277-5838
Email: leeyoung@huawei.com Email: leeyoung@huawei.com
Sugang Xu Sugang Xu
National Institute of Information and Communications Technology National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi, Koganei, 4-2-1 Nukui-Kitamachi, Koganei,
Tokyo, 184-8795 Japan Tokyo, 184-8795 Japan
skipping to change at page 17, line 26 skipping to change at line 705
Phone: +81 42-327-6927 Phone: +81 42-327-6927
Email: xsg@nict.go.jp Email: xsg@nict.go.jp
Giovanni Martinelli Giovanni Martinelli
Cisco Cisco
Via Philips 12 Via Philips 12
20052 Monza, IT 20052 Monza, IT
Phone: +39 039-209-2044 Phone: +39 039-209-2044
Email: giomarti@cisco.com Email: giomarti@cisco.com
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
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.
 End of changes. 52 change blocks. 
146 lines changed or deleted 150 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/