draft-ietf-pce-wson-rwa-ext-13.txt   draft-ietf-pce-wson-rwa-ext-14.txt 
Network Working Group Y. Lee, Ed. Network Working Group Y. Lee, Ed.
Internet Draft Huawei Technologies Internet Draft Huawei Technologies
Intended status: Standard Track R. Casellas, Ed. Intended status: Standard Track R. Casellas, Ed.
Expires: August 6, 2019 CTTC Expires: August 14, 2019 CTTC
February 7, 2019 February 15, 2019
PCEP Extension for WSON Routing and Wavelength Assignment PCEP Extension for WSON Routing and Wavelength Assignment
draft-ietf-pce-wson-rwa-ext-13 draft-ietf-pce-wson-rwa-ext-14
Abstract Abstract
This document provides the Path Computation Element communication This document provides the Path Computation Element communication
Protocol (PCEP) extensions for the support of Routing and Wavelength Protocol (PCEP) extensions for the support of Routing and Wavelength
Assignment (RWA) in Wavelength Switched Optical Networks (WSON). Assignment (RWA) in Wavelength Switched Optical Networks (WSON).
Path provisioning in WSONs requires a routing and wavelength Path provisioning in WSONs requires a routing and wavelength
assignment (RWA) process. From a path computation perspective, assignment (RWA) process. From a path computation perspective,
wavelength assignment is the process of determining which wavelength wavelength assignment is the process of determining which wavelength
can be used on each hop of a path and forms an additional routing can be used on each hop of a path and forms an additional routing
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 August 6, 2019. This Internet-Draft will expire on August 14, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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.
Table of Contents Table of Contents
1. Terminology....................................................3 1. Terminology....................................................3
2. Requirements Language..........................................3 2. Requirements Language..........................................3
3. Introduction...................................................3 3. Introduction...................................................3
4. Encoding of a RWA Path Request.................................6 4. Encoding of a RWA Path Request.................................6
4.1. Wavelength Assignment (WA) Object.........................6 4.1. Wavelength Assignment (WA) Object.........................7
4.2. Wavelength Selection TLV..................................8 4.2. Wavelength Selection TLV..................................9
4.3. Wavelength Restriction Constraint TLV.....................9 4.3. Wavelength Restriction Constraint TLV.....................9
4.3.1. Link Identifier Field...............................11 4.3.1. Link Identifier Field...............................12
4.3.2. Wavelength Restriction Field........................12 4.3.2. Wavelength Restriction Field........................13
4.4. Signal processing capability restrictions................14 4.4. Signal Processing Capability Restrictions................15
4.4.1. Signal Processing Exclusion XRO Subobject...........15 4.4.1. Signal Processing Exclusion.........................16
4.4.2. IRO subobject: signal processing inclusion..........16 4.4.2. Signal Processing Inclusion.........................18
5. Encoding of a RWA Path Reply..................................16 5. Encoding of a RWA Path Reply..................................18
5.1. Error Indicator..........................................18 5.1. Wavelength Allocation TLV................................18
5.2. NO-PATH Indicator........................................18 5.2. Error Indicator..........................................20
6. Manageability Considerations..................................19 5.3. NO-PATH Indicator........................................21
6.1. Control of Function and Policy...........................19 6. Manageability Considerations..................................21
6.2. Liveness Detection and Monitoring........................19 6.1. Control of Function and Policy...........................21
6.3. Verifying Correct Operation..............................20 6.2. Liveness Detection and Monitoring........................22
6.4. Requirements on Other Protocols and Functional Components20 6.3. Verifying Correct Operation..............................22
6.5. Impact on Network Operation..............................20 6.4. Requirements on Other Protocols and Functional Components22
7. Security Considerations.......................................20 6.5. Impact on Network Operation..............................22
8. IANA Considerations...........................................20
8.1. New PCEP Object..........................................20 7. Security Considerations.......................................22
8.2. New PCEP TLV: Wavelength Selection TLV...................21 8. IANA Considerations...........................................22
8.3. New PCEP TLV: Wavelength Restriction Constraint TLV......21 8.1. New PCEP Object: Wavelength Assignment Object............22
8.4. New PCEP TLV: Wavelength Allocation TLV..................21 8.2. WA Object Flag Field.....................................23
8.5. New PCEP TLV: Optical Interface Class List TLV...........22 8.3. New PCEP TLV: Wavelength Selection TLV...................23
8.6. New PCEP TLV: Client Signal TLV..........................22 8.4. New PCEP TLV: Wavelength Restriction Constraint TLV......24
8.7. New No-Path Reasons......................................22 8.5. Wavelength Restriction Constraint TLV Action Values......24
8.8. New Error-Types and Error-Values.........................23 8.6. New PCEP TLV: Wavelength Allocation TLV..................24
8.9. New Subobject for the Exclude Route Object...............23 8.7. Wavelength Allocation TLV Flag Field.....................25
8.10. New Subobject for the Include Route Object..............24 8.8. New PCEP TLV: Optical Interface Class List TLV...........25
9. Acknowledgments...............................................24 8.9. New PCEP TLV: Client Signal TLV..........................26
10. References...................................................24 8.10. New No-Path Reasons.....................................26
10.1. Normative References....................................24 8.11. New Error-Types and Error-Values........................26
10.2. Informative References..................................25 8.12. New SubobjectS for the Exclude Route Object.............27
11. Contributors.................................................27 8.13. New SubobjectS for the Include Route Object.............27
Authors' Addresses...............................................28 9. Acknowledgments...............................................28
10. References...................................................28
10.1. Normative References....................................28
10.2. Informative References..................................29
11. Contributors.................................................31
Authors' Addresses...............................................32
1. Terminology 1. Terminology
This document uses the terminology defined in [RFC4655], and This document uses the terminology defined in [RFC4655], and
[RFC5440]. [RFC5440].
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at page 7, line 38 skipping to change at page 8, line 5
<WA> <WA>
[other optional objects...] [other optional objects...]
If the WA object is present in the request, it MUST be encoded after If the WA object is present in the request, it MUST be encoded after
the END-POINTS object as defined in [PCEP-GMPLS]. The WA Object is the END-POINTS object as defined in [PCEP-GMPLS]. The WA Object is
mandatory in this document. Orderings for the other optional objects mandatory in this document. Orderings for the other optional objects
are irrelevant. are irrelevant.
WA Object-Class is (TBD1) (To be assigned by IANA).
WA Object-Type is 1.
The format of the WA object body is as follows: The format of the WA object body is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |M| | Reserved | Flags |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Wavelength Selection TLV | // TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| Wavelength Restriction Constraint TLV |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 WA Object Figure 3 WA Object
o Reserved (16 bits): Reserved for future use and SHOULD be zeroed o Reserved (16 bits): Reserved for future use and SHOULD be zeroed
and ignored on receipt. and ignored on receipt.
o Flags (16 bits) o Flags (16 bits)
One flag bit is allocated as follows: One flag bit is allocated as follows:
. M (Mode - 1 bit): M bit is used to indicate the mode of - M (Mode - 1 bit): M bit is used to indicate the mode of
wavelength assignment. When M bit is set to 1, this indicates wavelength assignment. When M bit is set to 1, this indicates
that the label assigned by the PCE must be explicit. That is, that the label assigned by the PCE must be explicit. That is,
the selected way to convey the allocated wavelength is by means the selected way to convey the allocated wavelength is by means
of Explicit Label Control for each hop of a computed LSP. of Explicit Label Control for each hop of a computed LSP.
Otherwise (M bit is set to 0), the label assigned by the PCE Otherwise (M bit is set to 0), the label assigned by the PCE
need not be explicit (i.e., it can be suggested in the form of need not be explicit (i.e., it can be suggested in the form of
label set objects in the corresponding response, to allow label set objects in the corresponding response, to allow
distributed WA. If M is 0, the PCE MUST return a Label Set distributed WA. If M is 0, the PCE MUST return a Label Set
Field as described in Section 2.6 of [RFC7579] in the response. Field as described in Section 2.6 of [RFC7579] in the response.
See Section 5 of this document for the encoding discussion of a See Section 5 of this document for the encoding discussion of a
Label Set Field in a PCRep message. Label Set Field in a PCRep message.
All unused flags SHOULD be zeroed. All unused flags SHOULD be zeroed. IANA is to create a new
registry to manage the Flag field of the WA object.
. Wavelength Selection TLV (32 bits): See Section 4.2 for o TLVs (variable). In the TLVs field, the following two TLVs are
defined. At least one TLV MUST be present.
- Wavelength Selection TLV (32 bits): See Section 4.2 for
details. details.
. Wavelength Restriction Constraint TLV (Variable): See Section - Wavelength Restriction Constraint TLV (Variable): See Section
4.3 for details. 4.3 for details.
4.2. Wavelength Selection TLV 4.2. Wavelength Selection TLV
The Wavelength Selection TLV is used to indicate the wavelength The Wavelength Selection TLV is used to indicate the wavelength
selection constraint in regard to the order of wavelength assignment selection constraint in regard to the order of wavelength assignment
to be returned by the PCE. This TLV is only applied when M bit is to be returned by the PCE. This TLV is only applied when M bit is
set in the WA Object specified in Section 4.1. This TLV MUST NOT be set in the WA Object specified in Section 4.1. This TLV MUST NOT be
used when the M bit is cleared. used when the M bit is cleared.
The encoding of this TLV is specified as the Wavelength Selection The encoding of this TLV is specified as the Wavelength Selection
Sub-TLV in Section 4.2.2 of [RFC7689]. Sub-TLV in Section 4.2.2 of [RFC7689]. IANA is to allocate a new TLV
type, Wavelength Selection TLV type (TBD2).
4.3. Wavelength Restriction Constraint TLV 4.3. Wavelength Restriction Constraint TLV
For any request that contains a wavelength assignment, the requester For any request that contains a wavelength assignment, the requester
(PCC) MUST specify a restriction on the wavelengths to be used. This (PCC) MUST specify a restriction on the wavelengths to be used. This
restriction is to be interpreted by the PCE as a constraint on the restriction is to be interpreted by the PCE as a constraint on the
tuning ability of the origination laser transmitter or on any other tuning ability of the origination laser transmitter or on any other
maintenance related constraints. Note that if the LSP LSC spans maintenance related constraints. Note that if the LSP LSC spans
different segments, the PCE must have mechanisms to know the different segments, the PCE must have mechanisms to know the
tunability restrictions of the involved wavelength converters / tunability restrictions of the involved wavelength converters /
regenerators, e.g. by means of the Traffic Engineering Database regenerators, e.g. by means of the Traffic Engineering Database
(TED) either via IGP or Network Management System (NMS). Even if the (TED) either via IGP or Network Management System (NMS). Even if the
PCE knows the tunability of the transmitter, the PCC must be able to PCE knows the tunability of the transmitter, the PCC must be able to
apply additional constraints to the request. apply additional constraints to the request.
The format of the Wavelength Restriction Constraint TLV is as The format of the Wavelength Restriction Constraint TLV is as
follows: follows:
<Wavelength Restriction Constraint> ::= <Wavelength Restriction Constraint> ::=
<Action> <Count> <Reserved> (<Action> <Count> <Reserved>
(<Link Identifiers> <Wavelength Restriction>)... <Link Identifiers> <Wavelength Restriction>)...
Where Where
<Link Identifiers> ::= <Link Identifier> [<Link Identifiers>] <Link Identifiers> ::= <Link Identifier> [<Link Identifiers>]
See Section 4.3.1. for the encoding of the Link Identifiers Field. See Section 4.3.1. for the encoding of the Link Identifiers Field.
<Link Identifiers> and <Wavelength Restriction> fields together MAY <Link Identifiers> and <Wavelength Restriction> fields MAY
appear more than once to be able to specify multiple restrictions. appear together more than once to be able to specify multiple
restrictions.
The Wavelength Restriction Constraint TLV type is TBD3 (See Section IANA is to allocate a new TLV type, Wavelength Restriction
8.3). Constraint TLV type (TBD3).
The TLV data is defined as follows: The TLV data is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Count | Reserved | | Action | Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifiers | | Link Identifiers Field |
| . . . | // . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength Restriction Field |
// . . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . . . ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifiers Field |
// . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength Restriction Field | | Wavelength Restriction Field |
// . . . . // // . . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Wavelength Restriction Constraint TLV Encoding Figure 4 Wavelength Restriction Constraint TLV Encoding
o Action (8 bits): o Action (8 bits):
. 0 - Inclusive List indicates that one or more link identifiers o 0 - Inclusive List indicates that one or more link
are included in the Link Set. Each identifies a separate link identifiers are included in the Link Set. Each identifies a
that is part of the set. separate link that is part of the set.
. 1 - Inclusive Range indicates that the Link Set defines a o 1 - Inclusive Range indicates that the Link Set defines a
range of links. It contains two link identifiers. The first range of links. It contains two link identifiers. The first
identifier indicates the start of the range (inclusive). The identifier indicates the start of the range (inclusive). The
second identifier indicates the end of the range (inclusive). second identifier indicates the end of the range
All links with numeric values between the bounds are (inclusive). All links with numeric values between the
considered to be part of the set. A value of zero in either bounds are considered to be part of the set. A value of zero
position indicates that there is no bound on the corresponding in either position indicates that there is no bound on the
portion of the range. corresponding portion of the range.
. 2-255 - For future use o 2-255 - For future use
IANA is to create a new registry to manage the Action values of the
Wavelength Restriction Constraint TLV.
Note that "links" are assumed to be bidirectional. Note that "links" are assumed to be bidirectional.
o Count (8 bits): The number of the link identifiers o Count (8 bits): The number of the link identifiers
Note that a PCC MAY add a Wavelength restriction that applies to all Note that a PCC MAY add a Wavelength restriction that applies to all
links by setting the Count field to zero and specifying just a set links by setting the Count field to zero and specifying just a set
of wavelengths. of wavelengths.
Note that all link identifiers in the same list must be of the same Note that all link identifiers in the same list MUST be of the same
type. type.
o Reserved (16 bits): Reserved for future use and SHOULD be zeroed o Reserved (16 bits): Reserved for future use and SHOULD be
and ignored on receipt. zeroed and ignored on receipt.
o Link Identifiers: Identifies each link ID for which restriction o Link Identifiers: Identifies each link ID for which
is applied. The length is dependent on the link format and the Count restriction is applied. The length is dependent on the link
field. See Section 4.3.1. for Link Identifier encoding and Section format and the Count field. See Section 4.3.1. for Link
4.3.2. for the Wavelength Restriction Field encoding, respectively. Identifier encoding.
o Wavelength Restriction: See Section 4.3.2. for the Wavelength
Restriction Field encoding.
Various encoding errors are possible with this TLV (e.g., not Various encoding errors are possible with this TLV (e.g., not
exactly two link identifiers with the range case, unknown identifier exactly two link identifiers with the range case, unknown identifier
types, no matching link for a given identifier, etc.). To indicate types, no matching link for a given identifier, etc.). To indicate
errors associated with this type, a new Error-Type (TBD8) and an errors associated with this encoding, a PCEP speaker MUST send a
Error-value (Error-value=3) are assigned so that the PCE MUST send a PCErr message with Error-Type=TBD8 and Error-value=3. See Section
PCErr message with a PCEP-ERROR Object. See Section 5.1 for the 5.1 for the details.
details.
4.3.1. Link Identifier Field 4.3.1. Link Identifier Field
The link identifier field can be an IPv4 [RFC3630], IPv6 [RFC5329] The link identifier field can be an IPv4 [RFC3630], IPv6 [RFC5329]
or unnumbered interface ID [RFC4203]. or unnumbered interface ID [RFC4203].
<Link Identifier> ::= <Link Identifier> ::=
<IPV4 Address> | <IPV6 Address> | <Unnumbered IF ID> <IPv4 Address> | <IPv6 Address> | <Unnumbered IF ID>
The encoding of each case is as follows: The encoding of each case is as follows:
IPv4 prefix sub-TLV IPv4 Address Field
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Reserved (16 bits) | | Type = 1 | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 bytes) | | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 prefix Sub-TLV IPv6 Address Field
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Reserved (16 bits) | | Type = 2 | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes) | | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | | IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | | IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | | IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unnumbered Interface ID Sub-TLV Unnumbered Interface ID Address Field
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Reserved (16 bits) | | Type = 3 | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Node ID (32 bits) | | TE Node ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) | | Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits): It indicates the type of the link identifier. o Type (8 bits): It indicates the type of the link identifier.
Reserved (16 bits): Reserved for future use and SHOULD be zeroed o Reserved (24 bits): Reserved for future use and SHOULD be
and ignored on receipt. zeroed and ignored on receipt.
The Type field is extensible. Please refer to the IANA registry o Link Identifier: When Type field is 1, 4-bytes IPv4 address
allocated for Link Management Protocol (LMP) [RFC4204]: is encoded; when Type field is 2, 16-bytes IPv6 address is
https://www.iana.org/assignments/lmp-parameters/lmp- encoded; when Type field is 3, a tuple of 4-bytes TE node
parameters.xhtml#lmp-parameters-15. ID and 4-bytes interface ID is encoded.
The Type field is extensible and matches to the IANA registry
created for Link Management Protocol (LMP) [RFC4204] for "TE Link
Object Class Type name space": https://www.iana.org/assignments/lmp-
parameters/lmp-parameters.xhtml#lmp-parameters-15.
4.3.2. Wavelength Restriction Field 4.3.2. Wavelength Restriction Field
The Wavelength Restriction Field of the Wavelength Restriction The Wavelength Restriction Field of the Wavelength Restriction
Constraint TLV is encoded as a Label Set field as specified in Constraint TLV is encoded as a Label Set field as specified in
Section 2.6 in [RFC7579] with base label encoded as a 32 bit LSC Section 2.6 in [RFC7579] with base label encoded as a 32 bit LSC
label, defined in [RFC6205]. The Label Set format is repeated here label, defined in [RFC6205]. The Label Set format is repeated here
for convenience, with the base label internal structure included. for convenience, with the base label internal structure included.
See [RFC6205] for a description of Grid, C.S, Identifier and n, as See [RFC6205] for a description of Grid, C.S, Identifier and n, as
well as [RFC7579] for the details of each action. well as [RFC7579] for the details of each action.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action| Num Labels | Length | | Action| Num Labels | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S | Identifier | n | |Grid | C.S | Identifier | n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional fields as necessary per action | | Additional fields as necessary per action |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 5 skipping to change at page 15, line 5
Identifier (9 bits): The value to be included in the "Identifier" Identifier (9 bits): The value to be included in the "Identifier"
field of the WDM label in RSVP-TE signaling, as defined in section field of the WDM label in RSVP-TE signaling, as defined in section
3.2 of [RFC6205]. The PCC MAY use the assigned value for the 3.2 of [RFC6205]. The PCC MAY use the assigned value for the
Identifier field in the corresponding LSP-related messages in RSVP- Identifier field in the corresponding LSP-related messages in RSVP-
TE signaling. TE signaling.
See Sections 2.6.1 - 2.6.3 of [RFC7579] for details on additional See Sections 2.6.1 - 2.6.3 of [RFC7579] for details on additional
field discussion for each action. field discussion for each action.
4.4. Signal processing capability restrictions 4.4. Signal Processing Capability Restrictions
Path computation for WSON includes checking of signal processing Path computation for WSON includes checking of signal processing
capabilities at each interface against requested capability; the PCE capabilities at each interface against requested capability; the PCE
MUST have mechanisms to know the signal processing capabilities at MUST have mechanisms to know the signal processing capabilities at
each interface, e.g. by means of the Traffic Engineering Database each interface, e.g. by means of the Traffic Engineering Database
(TED) either via IGP or Network Management System (NMS). Moreover, (TED) either via IGP or Network Management System (NMS). Moreover,
a PCC should be able to indicate additional restrictions to signal a PCC should be able to indicate additional restrictions to signal
processing compatibility, either on the endpoint or any given link. processing compatibility, either on the endpoint or any given link.
The supported signal processing capabilities considered in the RWA The supported signal processing capabilities considered in the RWA
Information Model [RFC7446] are: Information Model [RFC7446] are:
. Optical Interface Class List o Optical Interface Class List
. Bit Rate o Bit Rate
. Client Signal o Client Signal
The Bit Rate restriction is already expressed in [PCEP-GMPLS] in the The Bit Rate restriction is already expressed in [PCEP-GMPLS] in the
BANDWIDTH object. BANDWIDTH object.
In order to support the Optical Interface Class information and the In order to support the Optical Interface Class information and the
Client Signal information new TLVs are introduced as endpoint- Client Signal information new TLVs are introduced as endpoint-
restriction in the END-POINTS type Generalized endpoint: restriction in the END-POINTS type Generalized endpoint:
. Client Signal TLV o Client Signal TLV
. Optical Interface Class List TLV o Optical Interface Class List TLV
The END-POINTS type generalized endpoint is extended as follows: The END-POINTS type generalized endpoint is extended as follows:
<endpoint-restrictions> ::= <LABEL-REQUEST> <endpoint-restriction> ::=
<LABEL-REQUEST> <label-restriction-list>
<Wavelength Restriction Constraint> <label-restriction-list> ::= <label-restriction>
[<label-restriction-list>]
[<signal-compatibility-restriction>...] <label-restriction> ::= (<LABEL-SET>|
[<Wavelength Restriction Constraint>]
[<signal-compatibility-restriction>])
Where Where
signal-compatibility-restriction ::= <signal-compatibility-restriction> ::=
<Optical Interface Class List> <Client Signal> [<Optical Interface Class List>] [<Client Signal>]
The encoding for the Optical Interface Class List (TBD5) is The Wavelength Restriction Constraint TLV is defined in Section 4.3.
described in Section 4.1 of [RFC7581].
The encoding for the Client Signal Information (TBD6) is described A new TLV for the Optical Interface Class List TLV (TBD5) is
in Section 4.2 of [RFC7581]. defined, and the encoding of the value part of the Optical Interface
Class List TLV is described in Section 4.1 of [RFC7581].
4.4.1. Signal Processing Exclusion XRO Subobject A new TLV for the Client Signal Information TLV (TBD6) is defined,
and the encoding of the value part of the Client Signal Information
TLV is described in Section 4.2 of [RFC7581].
4.4.1. Signal Processing Exclusion
The PCC/PCE should be able to exclude particular types of signal The PCC/PCE should be able to exclude particular types of signal
processing along the path in order to handle client restriction or processing along the path in order to handle client restriction or
multi-domain path computation. [RFC5440] defines how Exclude Route multi-domain path computation. [RFC5440] defines how Exclude Route
Object (XRO) subobject is used. In this draft, we add a new XRO Object (XRO) subobject is used. In this draft, we add two new XRO
subobject, signal processing subobject. Signal Processing Exclusion Subobjects.
In order to support the exclusion a new XRO subobject is defined: The first XRO subobject type (TBD9) is the Optical Interface Class
the signal processing exclusion: List Field defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type =TBD | Length | Reserved | Attribute | |X| Type=TBD9 | Length | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-sub objects | // Optical Interface Class List //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 Signaling Processing XRO Subobject Figure 5 Optical Interface Class List XRO Subobject
Refer to [RFC5521] for the definition of X, Length and Attribute. Refer to [RFC5521] for the definition of X, Length and Attribute.
Type (7 bits): The Type of the XRO sub-sub objects. See below for Type (7 bits): The Type of the Signaling Processing Exclusion Field.
the two TBD values (TBD9 and TBD10) to be assigned by the IANA. The TLV Type value (TBD9) is to be assigned by the IANA for the
Optical Interface Class List XRO Subobject Type.
Reserved bits (8 bits) are for future use and SHOULD be zeroed and Reserved bits (8 bits) are for future use and SHOULD be zeroed and
ignored on receipt. ignored on receipt.
The Attribute field (8 bits): [RFC5521] defines several Attribute The Attribute field (8 bits): [RFC5521] defines several Attribute
values; the only permitted Attribute values for this subobject are values; the only permitted Attribute values for this field are 0
0 (Interface) or 1 (Node). (Interface) or 1 (Node).
The permitted sub-sub objects are the Optical Interface Class List The Optical Interface Class List is encoded as described in Section
and the Client Signal information whose encodings are described in 4.1 of [RFC7581].
Section 4.1 and Section 4.2 of [RFC7581], respectively.
The XRO needs to support the new subobject types: The second XRO subobject type (TBD10) is the Client Signal
Information defined as follows:
Type Sub-subobject 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type=TBD10 | Length | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Client Signal Information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Client Signal Information XRO Subobject
Refer to [RFC5521] for the definition of X, Length and Attribute.
Type (7 bits): The Type of the Signaling Processing Exclusion Field.
The TLV Type value (TBD10) is to be assigned by the IANA for the
Client Signal Information XRO Subobject Type.
Reserved bits (8 bits) are for future use and SHOULD be zeroed and
ignored on receipt.
The Attribute field (8 bits): [RFC5521] defines several Attribute
values; the only permitted Attribute values for this field are 0
(Interface) or 1 (Node).
The Client Signal Information is encoded as described in Section 4.2
of [RFC7581].
The XRO needs to support the new Signaling Processing Exclusion XRO
Subobject types:
Type XRO Subobject Type
TBD9 Optical Interface Class List TBD9 Optical Interface Class List
TBD10 Client Signal Information TBD10 Client Signal Information
4.4.2. IRO subobject: signal processing inclusion 4.4.2. Signal Processing Inclusion
Similar to the XRO subobject, the PCC/PCE should be able to include Similar to the XRO subobject, the PCC/PCE should be able to include
particular types of signal processing along the path in order to particular types of signal processing along the path in order to
handle client restriction or multi-domain path computation. handle client restriction or multi-domain path computation.
[RFC5440] defines how Include Route Object (IRO) subobject is used. [RFC5440] defines how Include Route Object (IRO) subobject is used.
In this draft, we add a new IRO subobject, signal processing In this draft, we add two new Signal Processing Inclusion
subobject. Subobjects.
The IRO needs to support the new subobject types as defined in The IRO needs to support the new IRO Subobject types (TBD11 and
Section 4.2 [RFC7689] "WSON Processing Hop Attribute TLV" (TBD9) TBD12) for the PCEP IRO object [RFC5440]:
defined for ERO in Section 4.2 [RFC7689] to the PCEP IRO object
[RFC5440]:
Type Sub-subobject Type IRO Subibject Type
TBD11 Optical Interface Class List TBD11 Optical Interface Class List
TBD12 Client Signal Information TBD12 Client Signal Information
The encoding of the Signal Processing Inclusion subobjects is
similar to Section 4.4.1 where the 'X' field is replaced with 'L'
field, all the other fields remains the same. The 'L' field is
described in [RFC3209].
5. Encoding of a RWA Path Reply 5. Encoding of a RWA Path Reply
This section provides the encoding of a RWA Path Reply for This section provides the encoding of a RWA Path Reply for
wavelength allocation request as discussed in Section 4. Recall that wavelength allocation request as discussed in Section 4.
wavelength allocation can be performed by the PCE by different
means: 5.1. Wavelength Allocation TLV
Recall that wavelength allocation can be performed by the PCE by
different means:
(a) By means of Explicit Label Control (ELC) where the PCE (a) By means of Explicit Label Control (ELC) where the PCE
allocates which label to use for each interface/node along the allocates which label to use for each interface/node along the
path. path.
(b) By means of a Label Set where the PCE provides a range of (b) By means of a Label Set where the PCE provides a range of
potential labels to allocate by each node along the path. potential labels to allocate by each node along the path.
Option (b) allows distributed label allocation (performed during Option (b) allows distributed label allocation (performed during
signaling) to complete wavelength allocation. signaling) to complete wavelength allocation.
The Wavelength Allocation TLV type is TBD4 (See Section 8.4). Note The Wavelength Allocation TLV type is TBD4 (See Section 8.4). Note
that this TLV is used for both (a) and (b). The TLV data is defined that this TLV is used for both (a) and (b). The TLV data is defined
as follows: as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |M| | Reserved | Flag |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier | | Link Identifier Field |
| . . . | // . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Allocated Wavelength(s) | | Allocated Wavelength(s) |
// . . . . // // . . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Wavelength Allocation TLV Encoding Figure 7 Wavelength Allocation TLV Encoding
o Reserved (15 bits): Reserved for future use. o Reserved (16 bits): Reserved for future use.
o M (Mode): 1 bit o Flags (16 bits)
- 0 indicates the allocation is under Explicit Label Control. One flag bit is allocated as follows:
. M (Mode): 1 bit
- 0 indicates the allocation is under Explicit Label Control.
- 1 indicates the allocation is expressed in Label Sets. - 1 indicates the allocation is expressed in Label Sets.
IANA is to create a new registry to manage the Flag field (TBD14) of
the Wavelength Allocation TLV.
Note that all link identifiers in the same list must be of the same Note that all link identifiers in the same list must be of the same
type. type.
o Link Identifier: Identifies the interface to which assignment o Link Identifier: Identifies the interface to which
wavelength(s) is applied. See Section 4.3.1. for Link Identifier assignment wavelength(s) is applied. See Section 4.3.1. for
encoding. Link Identifier encoding.
o Allocated Wavelength(s): Indicates the allocated wavelength(s) to o Allocated Wavelength(s): Indicates the allocated
be associated with the Link Identifier. See Section 4.3.2 for wavelength(s) to be associated with the Link Identifier. See
encoding details. Section 4.3.2 for encoding details.
This TLV is encoded as an attributes TLV, per [RFC5420], which is This TLV is carried in a PCRep message as an attribute TLV [RFC5420]
carried in the Hop Attribute Subobjects per [RFC7570]. in the Hop Attribute Subobjects [RFC7570] in the ERO [RFC5440].
5.1. Error Indicator 5.2. Error Indicator
To indicate errors associated with the RWA request, a new Error Type To indicate errors associated with the RWA request, a new Error Type
(TBD8) and subsequent error-values are defined as follows for (TBD8) and subsequent error-values are defined as follows for
inclusion in the PCEP-ERROR Object: inclusion in the PCEP-ERROR Object:
A new Error-Type (TBD8) and subsequent error-values are defined as A new Error-Type (TBD8) and subsequent error-values are defined as
follows: follows:
. Error-Type=TBD8; Error-value=1: if a PCE receives a RWA o Error-Type=TBD8; Error-value=1: if a PCE receives a RWA request
request and the PCE is not capable of processing the request and the PCE is not capable of processing the request due to
due to insufficient memory, the PCE MUST send a PCErr message insufficient memory, the PCE MUST send a PCErr message with a
with a PCEP-ERROR Object (Error-Type=TBD8) and an Error- PCEP-ERROR Object (Error-Type=TBD8) and an Error-value (Error-
value(Error-value=1). The PCE stops processing the request. value=1). The PCE stops processing the request. The
The corresponding RWA request MUST be cancelled at the PCC. corresponding RWA request MUST be cancelled at the PCC.
. Error-Type=TBD8; Error-value=2: if a PCE receives a RWA o Error-Type=TBD8; Error-value=2: if a PCE receives a RWA request
request and the PCE is not capable of RWA computation, the PCE and the PCE is not capable of RWA computation, the PCE MUST
MUST send a PCErr message with a PCEP-ERROR Object (Error- send a PCErr message with a PCEP-ERROR Object (Error-Type=TBD8)
Type=TBD8) and an Error-value (Error-value=2). The PCE stops and an Error-value (Error-value=2). The PCE stops processing
processing the request. The corresponding RWA computation the request. The corresponding RWA computation MUST be
MUST be cancelled at the PCC. cancelled at the PCC.
. Error-Type=TBD8; Error-value=3: if a PCE receives a RWA o Error-Type=TBD8; Error-value=3: if a PCE receives a RWA request
request and there are syntactical encoding errors (e.g., not and there are syntactical encoding errors (e.g., not exactly
exactly two link identifiers with the range case, unknown two link identifiers with the range case, unknown identifier
identifier types, no matching link for a given identifier, types, no matching link for a given identifier, etc.), the PCE
etc.), the PCE MUST send a PCErr message with a PCEP-ERROR MUST send a PCErr message with a PCEP-ERROR Object (Error-
Object (Error-Type=TBD8) and an Error-value (Error-value=3). Type=TBD8) and an Error-value (Error-value=3).
5.2. NO-PATH Indicator 5.3. NO-PATH Indicator
To communicate the reason(s) for not being able to find RWA for the To communicate the reason(s) for not being able to find RWA for the
path request, the NO-PATH object can be used in the corresponding path request, the NO-PATH object can be used in the corresponding
response. The format of the NO-PATH object body is defined in response. The format of the NO-PATH object body is defined in
[RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide
additional information about why a path computation has failed. additional information about why a path computation has failed.
One new bit flag is defined to be carried in the Flags field in the One new bit flag is defined to be carried in the Flags field in the
NO-PATH-VECTOR TLV carried in the NO-PATH Object. NO-PATH-VECTOR TLV carried in the NO-PATH Object.
. Bit TBD7: When set, the PCE indicates no feasible route was o Bit TBD7: When set, the PCE indicates no feasible route was
found that meets all the constraints (e.g., wavelength found that meets all the constraints (e.g., wavelength
restriction, signal compatibility, etc.) associated with RWA. restriction, signal compatibility, etc.) associated with RWA.
6. Manageability Considerations 6. Manageability Considerations
Manageability of WSON Routing and Wavelength Assignment (RWA) with Manageability of WSON Routing and Wavelength Assignment (RWA) with
PCE must address the following considerations: PCE must address the following considerations:
6.1. Control of Function and Policy 6.1. Control of Function and Policy
In addition to the parameters already listed in Section 8.1 of In addition to the parameters already listed in Section 8.1 of
[RFC5440], a PCEP implementation SHOULD allow configuration of the [RFC5440], a PCEP implementation SHOULD allow configuration of the
following PCEP session parameters on a PCC: following PCEP session parameters on a PCC:
. The ability to send a WSON RWA request. o The ability to send a WSON RWA request.
In addition to the parameters already listed in Section 8.1 of In addition to the parameters already listed in Section 8.1 of
[RFC5440], a PCEP implementation SHOULD allow configuration of the [RFC5440], a PCEP implementation SHOULD allow configuration of the
following PCEP session parameters on a PCE: following PCEP session parameters on a PCE:
. The support for WSON RWA. o The support for WSON RWA.
. A set of WSON RWA specific policies (authorized sender, o A set of WSON RWA specific policies (authorized sender,
request rate limiter, etc). request rate limiter, etc).
These parameters may be configured as default parameters for any These parameters may be configured as default parameters for any
PCEP session the PCEP speaker participates in, or may apply to a PCEP session the PCEP speaker participates in, or may apply to a
specific session with a given PCEP peer or a specific group of specific session with a given PCEP peer or a specific group of
sessions with a specific group of PCEP peers. sessions with a specific group of PCEP peers.
6.2. Liveness Detection and Monitoring 6.2. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
skipping to change at page 20, line 35 skipping to change at page 22, line 41
this document, this document does not introduce any new security this document, this document does not introduce any new security
issues. If an operator wishes to keep private the information issues. If an operator wishes to keep private the information
distributed by WSON, PCEPS [RFC8253] SHOULD be used. distributed by WSON, PCEPS [RFC8253] SHOULD be used.
8. IANA Considerations 8. IANA Considerations
IANA maintains a registry of PCEP parameters. IANA has made IANA maintains a registry of PCEP parameters. IANA has made
allocations from the sub-registries as described in the following allocations from the sub-registries as described in the following
sections. sections.
8.1. New PCEP Object 8.1. New PCEP Object: Wavelength Assignment Object
As described in Section 4.1, a new PCEP Object is defined to carry As described in Section 4.1, a new PCEP Object is defined to carry
wavelength assignment related constraints. IANA is to allocate the wavelength assignment related constraints. IANA is to allocate the
following from "PCEP Objects" sub-registry following from "PCEP Objects" sub-registry
(http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects): (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects):
Object Class Name Object Reference Object Class Name Object Reference
Value Type Value Type
--------------------------------------------------------- ---------------------------------------------------------
TBD1 WA 1: Wavelength-Assignment [This.I-D]
8.2. New PCEP TLV: Wavelength Selection TLV TBD1 WA 1: Wavelength Assignment [This.I-D]
8.2. WA Object Flag Field
As described in Section 4.1, IANA is to create a registry to manage
the Flag field of the WA object. New values are to be assigned by
Standards Action [RFC8126]. Each bit should be tracked with the
following qualities:
o Bit number (counting from bit 0 as the most significant bit)
o Capability description
o Defining RFC
The following values are defined in this document:
One bit is defined for the WA Object flag in this document:
Codespace of the Flag field (WA Object)
Bit Description Reference
-------------------------------------------------
15 explicit label control [This.I-D]
8.3. New PCEP TLV: Wavelength Selection TLV
As described in Sections 4.2, a new PCEP TLV is defined to indicate As described in Sections 4.2, a new PCEP TLV is defined to indicate
wavelength selection constraints. IANA is to allocate this new TLV wavelength selection constraints. IANA is to allocate this new TLV
from the "PCEP TLV Type Indicators" subregistry from the "PCEP TLV Type Indicators" subregistry
(http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-
indicators). indicators).
Value Description Reference Value Description Reference
--------------------------------------------------------- ---------------------------------------------------------
TBD2 Wavelength Selection [This.I-D] TBD2 Wavelength Selection [This.I-D]
8.3. New PCEP TLV: Wavelength Restriction Constraint TLV 8.4. New PCEP TLV: Wavelength Restriction Constraint TLV
As described in Sections 4.3, a new PCEP TLV is defined to indicate As described in Sections 4.3, a new PCEP TLV is defined to indicate
wavelength restriction constraints. IANA is to allocate this new TLV wavelength restriction constraints. IANA is to allocate this new TLV
from the "PCEP TLV Type Indicators" subregistry from the "PCEP TLV Type Indicators" subregistry
(http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-
indicators). indicators).
Value Description Reference Value Description Reference
--------------------------------------------------------- ---------------------------------------------------------
TBD3 Wavelength Restriction [This.I-D] TBD3 Wavelength Restriction [This.I-D]
Constraint Constraint
8.4. New PCEP TLV: Wavelength Allocation TLV 8.5. Wavelength Restriction Constraint TLV Action Values
As described in Section 4.3, IANA is to allocate a new registry to
manage the Action values of the Action field in the Wavelength
Restriction Constraint TLV. New values are assigned by Standards
Action [RFC8126]. Each value should be tracked with the following
qualities: value, meaning, and defining RFC. The following values
are defined in this document:
Value Meaning Reference
---------------------------------------------------------
0 Inclusive List [This.I-D]
1 Inclusive Range [This.I-D]
2-255 Reserved [This.I-D]
8.6. New PCEP TLV: Wavelength Allocation TLV
As described in Section 5, a new PCEP TLV is defined to indicate the As described in Section 5, a new PCEP TLV is defined to indicate the
allocation of wavelength(s) by the PCE in response to a request by allocation of wavelength(s) by the PCE in response to a request by
the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type
Indicators" subregistry Indicators" subregistry
(http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-
indicators). indicators).
Value Description Reference Value Description Reference
--------------------------------------------------------- ---------------------------------------------------------
TBD4 Wavelength Allocation [This.I-D] TBD4 Wavelength Allocation [This.I-D]
8.5. New PCEP TLV: Optical Interface Class List TLV 8.7. Wavelength Allocation TLV Flag Field
As described in Section 5, IANA is to allocate a registry to manage
the Flag field of the Wavelength Allocation TLV. New values are to
be assigned by Standards Action [RFC8126]. Each bit should be
tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit)
o Capability description
o Defining RFC
One bit is defined for the Wavelength Allocation flag in this -
document:
Codespace of the Flag field (Wavelength Allocation TLV)
Bit Description Reference
-------------------------------------------------
15 Wavelength Allocation Mode [This.I-D]
8.8. New PCEP TLV: Optical Interface Class List TLV
As described in Section 4.4, a new PCEP TLV is defined to indicate As described in Section 4.4, a new PCEP TLV is defined to indicate
the optical interface class list. IANA is to allocate this new TLV the optical interface class list. IANA is to allocate this new TLV
from the "PCEP TLV Type Indicators" subregistry from the "PCEP TLV Type Indicators" subregistry
(http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-
indicators). indicators).
Value Description Reference Value Description Reference
--------------------------------------------------------- ---------------------------------------------------------
TBD5 Optical Interface [This.I-D] TBD5 Optical Interface [This.I-D]
Class List Class List
8.6. New PCEP TLV: Client Signal TLV 8.9. New PCEP TLV: Client Signal TLV
As described in Section 4.4, a new PCEP TLV is defined to indicate As described in Section 4.4, a new PCEP TLV is defined to indicate
the client signal information. IANA is to allocate this new TLV from the client signal information. IANA is to allocate this new TLV from
the "PCEP TLV Type Indicators" subregistry the "PCEP TLV Type Indicators" subregistry
(http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-
indicators). indicators).
Value Description Reference Value Description Reference
--------------------------------------------------------- ---------------------------------------------------------
TBD6 Client Signal Information [This.I-D] TBD6 Client Signal Information [This.I-D]
8.7. New No-Path Reasons 8.10. New No-Path Reasons
As described in Section 5.2., a new bit flag are defined to be As described in Section 5.2, a new bit flag are defined to be
carried in the Flags field in the NO-PATH-VECTOR TLV carried in the carried in the Flags field in the NO-PATH-VECTOR TLV carried in the
NO-PATH Object. This flag, when set, indicates that no feasible NO-PATH Object. This flag, when set, indicates that no feasible
route was found that meets all the RWA constraints (e.g., wavelength route was found that meets all the RWA constraints (e.g., wavelength
restriction, signal compatibility, etc.) associated with a RWA path restriction, signal compatibility, etc.) associated with a RWA path
computation request. computation request.
IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR
TLV Flag Field" subregistry TLV Flag Field" subregistry
(http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector- (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector-
tlv). tlv).
Bit Description Reference Bit Description Reference
----------------------------------------------------- -----------------------------------------------------
TBD7 No RWA constraints met [This.I-D] TBD7 No RWA constraints met [This.I-D]
8.8. New Error-Types and Error-Values 8.11. New Error-Types and Error-Values
As described in Section 5.1, new PCEP error codes are defined for As described in Section 5.1, new PCEP error codes are defined for
WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object
Error Types and Values" sub-registry Error Types and Values" sub-registry
(http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object). (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object).
Error- Meaning Error-Value Reference Error- Meaning Error-Value Reference
Type Type
--------------------------------------------------------------- ---------------------------------------------------------------
TBD8 WSON RWA Error 1: Insufficient [This.I-D] TBD8 WSON RWA Error 1: Insufficient [This.I-D]
Memory Memory
2: RWA computation [This.I-D] 2: RWA computation [This.I-D]
Not supported Not supported
3: Syntactical [This.I-D] 3: Syntactical [This.I-D]
Encoding error Encoding error
8.9. New Subobject for the Exclude Route Object 8.12. New Subobjects for the Exclude Route Object
The "PCEP Parameters" registry contains a subregistry "PCEP Objects" As described in Section 4.4.1, the "PCEP Parameters" registry
with an entry for the Exclude Route Object (XRO). IANA is requested contains a subregistry "PCEP Objects" with an entry for the Exclude
to add a further subobject that can be carried in the XRO as Route Object (XRO). IANA is requested to add further subobjects that
follows: can be carried in the XRO as follows:
Subobject Type Reference Subobject Type Reference
---------------------------------------------------------- ----------------------------------------------------------
TBD9 Optical Interface Class List [This.I-D] TBD9 Optical Interface Class List [This.I-D]
TBD10 Client Signal Information [This.I-D] TBD10 Client Signal Information [This.I-D]
8.10. New Subobject for the Include Route Object 8.13. New Subobjects for the Include Route Object
The "PCEP Parameters" registry contains a subregistry "PCEP Objects" As described in Section 4.4.2, the "PCEP Parameters" registry
with an entry for the Include Route Object (IRO). IANA is requested contains a subregistry "PCEP Objects" with an entry for the Include
to add a further subobject that can be carried in the IRO as Route Object (IRO). IANA is requested to add further subobjects that
follows: can be carried in the IRO as follows:
Subobject Type Reference Subobject Type Reference
---------------------------------------------------------- ----------------------------------------------------------
TBD11 Optical Interface Class List [This.I-D] TBD11 Optical Interface Class List [This.I-D]
TBD12 Client Signal Information [This.I-D] TBD12 Client Signal Information [This.I-D]
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Adrian Farrel and Julien Meuric for The authors would like to thank Adrian Farrel, Julien Meuric and
many helpful comments that greatly improved the contents of this Dhruv Dhody for many helpful comments that greatly improved the
draft. contents of this draft.
10. References 10. References
10.1. Normative References 10.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.
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan,
G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE) [RFC3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE)
Extensions to OSPF Version 2", RFC 3630, September 2003. Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC5329] A. Lindem, Ed., "Traffic Engineering Extensions to OSPF [RFC5329] A. Lindem, Ed., "Traffic Engineering Extensions to OSPF
Version 3", RFC 5329, September 2008. Version 3", RFC 5329, September 2008.
[RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation [RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009. March 2009.
skipping to change at page 27, line 5 skipping to change at page 30, line 22
[RFC7449] Y. Lee, G. Bernstein, (Editors), "Path Computation Element [RFC7449] Y. Lee, G. Bernstein, (Editors), "Path Computation Element
Communication Protocol (PCEP) Requirements for Wavelength Communication Protocol (PCEP) Requirements for Wavelength
Switched Optical Network (WSON) Routing and Wavelength Switched Optical Network (WSON) Routing and Wavelength
Assignment", RFC 7449, February 2015. Assignment", RFC 7449, February 2015.
[PCEP-LS] Y. Lee, et al., "PCEP Extension for Distribution of Link- [PCEP-LS] Y. Lee, et al., "PCEP Extension for Distribution of Link-
State and TE information for Optical Networks", draft-lee- State and TE information for Optical Networks", draft-lee-
pce-pcep-ls-optical, work in progress. pce-pcep-ls-optical, work in progress.
[RFC8126] M. Cotton, B. Leiba, T,.Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 8126, June 2017.
11. Contributors 11. Contributors
Fatai Zhang Fatai Zhang
Huawei Technologies Huawei Technologies
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Cyril Margaria Cyril Margaria
Nokia Siemens Networks Nokia Siemens Networks
St Martin Strasse 76 St Martin Strasse 76
Munich, 81541 Munich, 81541
 End of changes. 113 change blocks. 
220 lines changed or deleted 374 lines changed or added

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