draft-ietf-pce-wson-rwa-ext-11.txt   draft-ietf-pce-wson-rwa-ext-12.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: July 14, 2019 CTTC Expires: August 5, 2019 CTTC
January 14, 2019 February 6, 2019
PCEP Extension for WSON Routing and Wavelength Assignment PCEP Extension for WSON Routing and Wavelength Assignment
draft-ietf-pce-wson-rwa-ext-11 draft-ietf-pce-wson-rwa-ext-12
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 July 14, 2019. This Internet-Draft will expire on August 5, 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 32 skipping to change at page 2, line 32
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.........................6
4.2. Wavelength Selection TLV..................................8 4.2. Wavelength Selection TLV..................................8
4.3. Wavelength Restriction Constraint TLV.....................8 4.3. Wavelength Restriction Constraint TLV.....................9
4.3.1. Link Identifier Field...............................11 4.3.1. Link Identifier Field...............................11
4.3.2. Wavelength Restriction Field........................12 4.3.2. Wavelength Restriction Field........................12
4.4. Signal processing capability restrictions................13 4.4. Signal processing capability restrictions................13
4.4.1. Signal Processing Exclusion XRO Sub-Object..........14 4.4.1. Signal Processing Exclusion XRO Sub-Object..........15
4.4.2. IRO sub-object: signal processing inclusion.........15 4.4.2. IRO sub-object: signal processing inclusion.........16
5. Encoding of a RWA Path Reply..................................15 5. Encoding of a RWA Path Reply..................................16
5.1. Error Indicator..........................................17 5.1. Error Indicator..........................................18
5.2. NO-PATH Indicator........................................17 5.2. NO-PATH Indicator........................................18
6. Manageability Considerations..................................18 6. Manageability Considerations..................................19
6.1. Control of Function and Policy...........................18 6.1. Control of Function and Policy...........................19
6.2. Liveness Detection and Monitoring........................18 6.2. Liveness Detection and Monitoring........................19
6.3. Verifying Correct Operation..............................18 6.3. Verifying Correct Operation..............................19
6.4. Requirements on Other Protocols and Functional Components19 6.4. Requirements on Other Protocols and Functional Components20
6.5. Impact on Network Operation..............................19 6.5. Impact on Network Operation..............................20
7. Security Considerations.......................................19 7. Security Considerations.......................................20
8. IANA Considerations...........................................19 8. IANA Considerations...........................................20
8.1. New PCEP Object..........................................19 8.1. New PCEP Object..........................................20
8.2. New PCEP TLV: Wavelength Selection TLV...................20 8.2. New PCEP TLV: Wavelength Selection TLV...................21
8.3. New PCEP TLV: Wavelength Restriction Constraint TLV......20 8.3. New PCEP TLV: Wavelength Restriction Constraint TLV......21
8.4. New PCEP TLV: Wavelength Allocation TLV..................20 8.4. New PCEP TLV: Wavelength Allocation TLV..................21
8.5. New PCEP TLV: Optical Interface Class List TLV...........21 8.5. New PCEP TLV: Optical Interface Class List TLV...........22
8.6. New PCEP TLV: Client Signal TLV..........................21 8.6. New PCEP TLV: Client Signal TLV..........................22
8.7. New No-Path Reasons......................................21 8.7. New No-Path Reasons......................................22
8.8. New Error-Types and Error-Values.........................22 8.8. New Error-Types and Error-Values.........................23
9. Acknowledgments...............................................22 8.9. New Sub-object for the Exclude Route Object..............23
10. References...................................................22 8.10. New Sub-object for the Include Route Object.............24
10.1. Normative References....................................22 9. Acknowledgments...............................................24
10.2. Informative References..................................23 10. References...................................................24
11. Contributors.................................................24 10.1. Normative References....................................24
Authors' Addresses...............................................25 10.2. Informative References..................................25
11. Contributors.................................................27
Authors' Addresses...............................................28
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 4, line 19 skipping to change at page 4, line 20
Optical Networks (WSON) based on the requirements specified in Optical Networks (WSON) based on the requirements specified in
[RFC6163] and [RFC7449]. [RFC6163] and [RFC7449].
WSON refers to WDM based optical networks in which switching is WSON refers to WDM based optical networks in which switching is
performed selectively based on the wavelength of an optical signal. performed selectively based on the wavelength of an optical signal.
The devices used in WSONs that are able to switch signals based on The devices used in WSONs that are able to switch signals based on
signal wavelength are known as Lambda Switch Capable (LSC). WSONs signal wavelength are known as Lambda Switch Capable (LSC). WSONs
can be transparent or translucent. A transparent optical network is can be transparent or translucent. A transparent optical network is
made up of optical devices that can switch but not convert from one made up of optical devices that can switch but not convert from one
wavelength to another, all within the optical domain. On the other wavelength to another, all within the optical domain. On the other
hand, translucent networks include 3R regenerators that are sparsely hand, translucent networks include 3R regenerators (Re-
placed. The main function of the 3R regenerators is to convert one amplification, Re-shaping, Re-timing) that are sparsely placed. The
optical wavelength to another. main function of the 3R regenerators is to convert one optical
wavelength to another.
A Lambda Switch Capable (LSC) Label Switched Path (LSP) may span one A Lambda Switch Capable (LSC) Label Switched Path (LSP) may span one
or several transparent segments, which are delimited by 3R or several transparent segments, which are delimited by 3R
regenerators (Re-amplification, Re-shaping, Re-timing) typically regenerators typically with electronic regenerator and optional
with electronic regenerator and optional wavelength conversion. Each wavelength conversion. Each transparent segment or path in WSON is
transparent segment or path in WSON is referred to as an optical referred to as an optical path. An optical path may span multiple
path. An optical path may span multiple fiber links and the path fiber links and the path should be assigned the same wavelength for
should be assigned the same wavelength for each link. In such case, each link. In such case, the optical path is said to satisfy the
the optical path is said to satisfy the wavelength-continuity wavelength-continuity constraint. Figure 1 illustrates the
constraint. Figure 1 illustrates the relationship between a LSC LSP relationship between a LSC LSP and transparent segments (optical
and transparent segments (optical paths). paths).
+---+ +-----+ +-----+ +-----+ +-----+ +---+ +-----+ +-----+ +-----+ +-----+
| |I1 | | | | | | I2| | | |I1 | | | | | | I2| |
| |o------| |-------[(3R) ]------| |--------o| | | |o------| |-------[(3R) ]------| |--------o| |
| | | | | | | | | | | | | | | | | | | |
+---+ +-----+ +-----+ +-----+ +-----+ +---+ +-----+ +-----+ +-----+ +-----+
(X LSC) (LSC LSC) (LSC LSC) (LSC X) (X LSC) (LSC LSC) (LSC LSC) (LSC X)
<-------> <-------> <-----> <-------> <-------> <-------> <-----> <------->
<-----------------------><----------------------> <-----------------------><---------------------->
Transparent Segment Transparent Segment Transparent Segment Transparent Segment
skipping to change at page 5, line 35 skipping to change at page 5, line 35
additional routing constraint to be considered in all optical path additional routing constraint to be considered in all optical path
computation. computation.
For example (see Figure 1), within a translucent WSON, a LSC LSP may For example (see Figure 1), within a translucent WSON, a LSC LSP may
be established between interfaces I1 and I2, spanning 2 transparent be established between interfaces I1 and I2, spanning 2 transparent
segments (optical paths) where the wavelength continuity constraint segments (optical paths) where the wavelength continuity constraint
applies (i.e. the same unique wavelength must be assigned to the LSP applies (i.e. the same unique wavelength must be assigned to the LSP
at each TE link of the segment). If the LSC LSP induced a Forwarding at each TE link of the segment). If the LSC LSP induced a Forwarding
Adjacency / TE link, the switching capabilities of the TE link would Adjacency / TE link, the switching capabilities of the TE link would
be (X X) where X refers to the switching capability of I1 and I2. be (X X) where X refers to the switching capability of I1 and I2.
For example, X can be PSC, TDM, etc. For example, X can be Packet Switch Capable (PSC), Time Division
Multiplexing (TDM), etc.
This document aligns with GMPLS extensions for PCEP [PCEP-GMPLS] for This document aligns with GMPLS extensions for PCEP [PCEP-GMPLS] for
generic properties such as label, label-set and label assignment generic properties such as label, label-set and label assignment
noting that wavelength is a type of label. Wavelength restrictions noting that wavelength is a type of label. Wavelength restrictions
and constraints are also formulated in terms of labels per and constraints are also formulated in terms of labels per
[RFC7579]. [RFC7579].
The optical modulation properties, which are also referred to as The optical modulation properties, which are also referred to as
signal compatibility, are already considered in signaling in signal compatibility, are already considered in signaling in
[RFC7581] and [RFC7688]. In order to improve the signal quality and [RFC7581] and [RFC7688]. In order to improve the signal quality and
limit some optical effects several advanced modulation processing limit some optical effects several advanced modulation processing
capabilities are used. These modulation capabilities contribute not capabilities are used. These modulation capabilities contribute not
only to optical signal quality checks but also constrain the only to optical signal quality checks but also constrain the
selection of sender and receiver, as they should have matching selection of sender and receiver, as they should have matching
signal processing capabilities. This document includes signal signal processing capabilities. This document includes signal
compatibility constraints as part of RWA path computation. That is, compatibility constraints as part of RWA path computation. That is,
the signal processing capabilities (e.g., modulation and FEC) the signal processing capabilities (e.g., modulation and Forward
indicated by means of optical interface class (OIC) must be Error Correction (FEC)) indicated by means of optical interface
compatible between the sender and the receiver of the optical path class (OIC) must be compatible between the sender and the receiver
across all optical elements. of the optical path across all optical elements.
This document, however, does not address optical impairments as part This document, however, does not address optical impairments as part
of RWA path computation. of RWA path computation. See [RFC6566] for the framework for optical
impairments.
4. Encoding of a RWA Path Request 4. Encoding of a RWA Path Request
Figure 2 shows one typical PCE based implementation, which is Figure 2 shows one typical PCE based implementation, which is
referred to as the Combined Process (R&WA). With this architecture, referred to as the Combined Process (R&WA). With this architecture,
the two processes of routing and wavelength assignment are accessed the two processes of routing and wavelength assignment are accessed
via a single PCE. This architecture is the base architecture via a single PCE. This architecture is the base architecture
specified in [RFC6163] and the PCEP extensions that are specified in specified in [RFC6163] and the PCEP extensions that are specified in
this document are based on this architecture. this document are based on this architecture.
skipping to change at page 7, line 6 skipping to change at page 7, line 9
allocates which label to use for each interface/node along the path. allocates which label to use for each interface/node along the path.
The allocated labels MAY appear after an interface route subobject. The allocated labels MAY appear after an interface route subobject.
(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 assignment. signaling) to complete wavelength assignment.
Additionally, given a range of potential labels to allocate, the Additionally, given a range of potential labels to allocate, the
request SHOULD convey the heuristic / mechanism to the allocation. request SHOULD convey the heuristic / mechanism used for the
allocation.
The format of a PCReq message after incorporating the Wavelength The format of a PCReq message per [RFC5440] after incorporating the
Assignment (WA) object is as follows: Wavelength Assignment (WA) object is as follows:
<PCReq Message> ::= <Common Header> <PCReq Message> ::= <Common Header>
[<svec-list>] [<svec-list>]
<request-list> <request-list>
Where: Where:
<request-list>::=<request>[<request-list>] <request-list>::=<request>[<request-list>]
<request>::= <RP> <request>::= <RP>
<ENDPOINTS> <END-POINTS>
<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 ENDPOINTS object as defined in [PCEP-GMPLS]. Orderings with the END-POINTS object as defined in [PCEP-GMPLS]. The WA Object is
respect to the other following objects are irrelevant. mandatory in this document. Orderings for the other optional objects
are irrelevant.
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 | | Wavelength Selection TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength Restriction Constraint TLV | | 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.
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.
skipping to change at page 9, line 4 skipping to change at page 9, line 14
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 be able to specify a restriction on the wavelengths to be (PCC) MUST be able to specify a restriction on the wavelengths to be
used. This restriction is to be interpreted by the PCE as a used. This restriction is to be interpreted by the PCE as a
constraint on the tuning ability of the origination laser constraint on the tuning ability of the origination laser
transmitter or on any other maintenance related constraints. Note transmitter or on any other maintenance related constraints. Note
that if the LSP LSC spans different segments, the PCE MUST have that if the LSP LSC spans different segments, the PCE MUST have
mechanisms to know the tunability restrictions of the involved mechanisms to know the tunability restrictions of the involved
wavelength converters / regenerators, e.g. by means of the TED wavelength converters / regenerators, e.g. by means of the Traffic
either via IGP or NMS. Even if the PCE knows the tunability of the Engineering Database (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 apply additional constraints to transmitter, the PCC MUST be able to apply additional constraints to
the request. 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
appear more than once to be able to specify multiple restrictions.
The Wavelength Restriction Constraint TLV type is TBD3 (See Section The Wavelength Restriction Constraint TLV type is TBD3 (See Section
8.3). This TLV MAY appear more than once to be able to specify 8.3).
multiple restrictions.
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 |
| . . . | | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength Restriction Field | | Wavelength Restriction Field |
// . . . . // // . . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Wavelength Restriction Constraint TLV Encoding Figure 4 Wavelength Restriction Constraint TLV Encoding
skipping to change at page 10, line 20 skipping to change at page 10, line 28
. 1 - Inclusive Range indicates that the Link Set defines a . 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 (inclusive).
All links with numeric values between the bounds are All links with numeric values between the bounds are
considered to be part of the set. A value of zero in either considered to be part of the set. A value of zero in either
position indicates that there is no bound on the corresponding position indicates that there is no bound on the corresponding
portion of the range. portion of the range.
Note that "interfaces" are assumed to be bidirectional. . 2-255 - For future use
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 zeroed
and ignored on receipt.
o Link Identifiers: Identifies each link ID for which restriction o Link Identifiers: Identifies each link ID for which restriction
is applied. The length is dependent on the link format and the Count is applied. The length is dependent on the link format and the Count
field. See Section 4.3.1. for Link Identifier encoding and Section field. See Section 4.3.1. for Link Identifier encoding and Section
4.3.2. for the Wavelength Restriction Field encoding, respectively. 4.3.2. for the Wavelength Restriction Field encoding, respectively.
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 type, a new Error-Type (TBD8) and an
Error-value (Error-value=3) MUST be defined so that the PCE MUST Error-value (Error-value=3) are assigned so that the PCE MUST send a
send a PCErr message with a PCEP-ERROR Object. See Section 5.1 for PCErr message with a PCEP-ERROR Object. See Section 5.1 for the
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>
skipping to change at page 12, line 14 skipping to change at page 12, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Reserved (16 bits) | | Type = 3 | Reserved (16 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. Type (8 bits): It indicates the type of the link identifier.
Reserved (16 bits): Reserved for future use and SHOULD be zeroed. Reserved (16 bits): Reserved for future use and SHOULD be zeroed
and ignored on receipt.
4.3.2. Wavelength Restriction Field 4.3.2. Wavelength Restriction Field
The Wavelength Restriction Field of the wavelength restriction TLV The Wavelength Restriction Field of the wavelength restriction TLV
is encoded as a Label Set field as specified in Section 2.6 in is encoded as a Label Set field as specified in Section 2.6 in
[RFC7579] with base label encoded as a 32 bit LSC label, defined in [RFC7579] with base label encoded as a 32 bit LSC label, defined in
[RFC6205]. See [RFC6205] for a description of Grid, C.S, Identifier [RFC6205]. The Label Set format is repeated here for convenience,
and n, as well as [RFC7579] for the details of each action. with the base label internal structure included. See [RFC6205] for a
description of Grid, C.S, Identifier and n, as 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 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Action (4 bits): Action (4 bits):
skipping to change at page 13, line 4 skipping to change at page 13, line 22
Action (4 bits): Action (4 bits):
0 - Inclusive List 0 - Inclusive List
1 - Exclusive List 1 - Exclusive List
2 - Inclusive Range 2 - Inclusive Range
3 - Exclusive Range 3 - Exclusive Range
4 - Bitmap Set 4 - Bitmap Set
Num Labels (12 bits): It is generally the number of labels. It has a Num Labels (12 bits): It is generally the number of labels. It has a
specific meaning depending on the action value. specific meaning depending on the action value.
Length (16 bits): It is the length in bytes of the entire label set Length (16 bits): It is the length in bytes of the entire Wavelength
field. Restriction field.
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; this capabilities at each interface against requested capability; the PCE
requirement MAY be implemented by the IGP. Moreover, a PCC should MUST have mechanisms to know the signal processing capabilities at
be able to indicate additional restrictions to signal processing each interface, e.g. by means of the Traffic Engineering Database
compatibility, either on the endpoint or any given link. (TED) either via IGP or Network Management System (NMS). Moreover,
a PCC should be able to indicate additional restrictions to signal
processing compatibility, either on the endpoint or any given link.
The supported signal processing capabilities are those described in The supported signal processing capabilities considered in the RWA
[RFC7446]: Information Model [RFC7446] are:
. Optical Interface Class List . Optical Interface Class List
. Bit Rate . Bit Rate
. Client Signal . 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.
skipping to change at page 14, line 14 skipping to change at page 14, line 39
<Wavelength Restriction Constraint> <Wavelength Restriction Constraint>
[<signal-compatibility-restriction>...] [<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 is described in The encoding for the Optical Interface Class List (TBD5) is
Section 4.1 of [RFC7581]. described in Section 4.1 of [RFC7581].
The encoding for the Client Signal Information is described in The encoding for the Client Signal Information (TBD6) is described
Section 4.2 of [RFC7581]. in Section 4.2 of [RFC7581].
4.4.1. Signal Processing Exclusion XRO Sub-Object 4.4.1. Signal Processing Exclusion XRO Sub-Object
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) sub-object is used. In this draft, we add a new XRO Object (XRO) sub-object is used. In this draft, we add a new XRO
sub-object, signal processing sub-object. sub-object, signal processing sub-object.
In order to support the exclusion a new XRO sub-object is defined: In order to support the exclusion a new XRO sub-object is defined:
the signal processing exclusion: the signal processing exclusion:
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 = X | Length | Reserved | Attribute | |X| Type =TBD | Length | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-sub objects | | sub-sub objects |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 Signaling Processing XRO Sub-Object Figure 5 Signaling Processing XRO Sub-Object
Refer to [RFC5521] for the definition of X, Type, Length and Refer to [RFC5521] for the definition of X, Length and Attribute.
Attribute.
Reserved bits (8 bits) are for future use and SHOULD be zeroed. Type (7 bits): The Type of the XRO sub-sub objects. See below for
the two TBD values (TBD9 and TBD10) to be assigned by the IANA.
The Attribute field (8 bits) indicates how the exclusion sub-object Reserved bits (8 bits) are for future use and SHOULD be zeroed and
is to be interpreted. The Attribute can only be 0 (Interface) or 1 ignored on receipt.
(Node).
The Attribute field (8 bits): [RFC5521] defines several Attribute
values; the only permitted Attribute values for this sub-object are
0 (Interface) or 1 (Node).
The permitted sub-sub objects are the Optical Interface Class List The permitted sub-sub objects are the Optical Interface Class List
and the Client Signal information whose encodings are described in and the Client Signal information whose encodings are described in
Section 4.1 and Section 4.2 of [RFC7581], respectively. Section 4.1 and Section 4.2 of [RFC7581], respectively.
The XRO needs to support the new sub-object types:
Type Sub-sub object
TBD9 Optical Interface Class List
TBD10 Client Signal Information
4.4.2. IRO sub-object: signal processing inclusion 4.4.2. IRO sub-object: signal processing inclusion
Similar to the XRO sub-object, the PCC/PCE should be able to include Similar to the XRO sub-object, 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) sub-object is used. [RFC5440] defines how Include Route Object (IRO) sub-object is used.
In this draft, we add a new IRO sub-object, signal processing sub- In this draft, we add a new IRO sub-object, signal processing sub-
object. object.
This is supported by adding the sub-object "WSON Processing Hop The IRO needs to support the new sub-object types as defined in
Attribute TLV" defined for ERO in Section 4.2 [RFC7689] to the PCEP Section 4.2 [RFC7689] "WSON Processing Hop Attribute TLV" (TBD9)
IRO object [RFC5440]. defined for ERO in Section 4.2 [RFC7689] to the PCEP IRO object
[RFC5440]:
Type Sub-sub-object
TBD11 Optical Interface Class List
TBD12 Client Signal Information
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. Recall that
wavelength allocation can be performed by the PCE by different wavelength allocation can be performed by the PCE by different
means: 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). The The Wavelength Allocation TLV type is TBD4 (See Section 8.4). Note
TLV data is defined as follows: that this TLV is used for both (a) and (b). 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |M| | Reserved |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier | | Link Identifier |
| . . . | | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Allocated Wavelength(s) | | Allocated Wavelength(s) |
// . . . . // // . . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Wavelength Allocation TLV Encoding Figure 6 Wavelength Allocation TLV Encoding
o Type (16 bits): The type of the TLV. o Reserved (15 bits): Reserved for future use.
o Length (15 bits): The length of the TLV including the Type and
Length fields.
o M (Mode): 1 bit o M (Mode): 1 bit
- 0 indicates the allocation is under Explicit Label Control. - 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.
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 assignment
wavelength(s) is applied. See Section 4.3.1. for Link Identifier wavelength(s) is applied. See Section 4.3.1. for Link Identifier
encoding. encoding.
o Allocated Wavelength(s): Indicates the allocated wavelength(s) to o Allocated Wavelength(s): Indicates the allocated wavelength(s) to
be associated with the Link Identifier. See Section 4.3.2 for be associated with the Link Identifier. See Section 4.3.2 for
encoding details. encoding details.
This TLV is encoded as an attributes TLV, per [RFC5420], which is This TLV is encoded as an attributes TLV, per [RFC5420], which is
carried in the ERO LSP Attribute Subobjects per [RFC7570]. carried in the Hop Attribute Subobjects per [RFC7570].
5.1. Error Indicator 5.1. 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:
skipping to change at page 21, line 7 skipping to change at page 22, line 7
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.5. New PCEP TLV: Optical Interface Class List TLV
As described in Section 4.3, 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.6. New PCEP TLV: Client Signal TLV
As described in Section 4.3, 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.7. New No-Path Reasons
skipping to change at page 22, line 25 skipping to change at page 23, line 25
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]
Encoding error
8.9. New Sub-object for the Exclude Route Object
The "PCEP Parameters" registry contains a subregistry "PCEP Objects"
with an entry for the Exclude Route Object (XRO). IANA is requested
to add a further subobject that can be carried in the XRO as
follows:
Sub-object Type Reference
----------------------------------------------------------
TBD9 Optical Interface Class List [This.I-D]
TBD10 Client Signal Information [This.I-D]
8.10. New Sub-object for the Include Route Object
The "PCEP Parameters" registry contains a subregistry "PCEP Objects"
with an entry for the Include Route Object (IRO). IANA is requested
to add a further subobject that can be carried in the IRO as
follows:
Sub-object Type Reference
----------------------------------------------------------
TBD11 Optical Interface Class List [This.I-D]
TBD12 Client Signal Information [This.I-D]
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Adrian Farrel for many helpful The authors would like to thank Adrian Farrel for many helpful
comments that greatly improved the contents of this draft. comments that greatly improved the contents of this draft.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 24, line 9 skipping to change at page 25, line 43
10.2. Informative References 10.2. Informative References
[RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC Switching (GMPLS) Signaling Functional Description", RFC
3471. January 2003. 3471. January 2003.
[RFC4203] K. Kompella, Ed., Y. Rekhter, Ed., "OSPF Extensions in [RFC4203] K. Kompella, Ed., Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005. (GMPLS)", RFC 4203, October 2005.
[RFC4655] A. Farrel, JP. Vasseur, G. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP [RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC5420, February 2009. Engineering (RSVP-TE)", RFC5420, February 2009.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) communication Protocol", RFC 5440, March Element (PCE) communication Protocol", RFC 5440, March
2009.[RFC5521] Oki, E, T. Takeda, and A. Farrel, 2009.[RFC5521] Oki, E, T. Takeda, and A. Farrel,
"Extensions to the Path Computation Element Communication "Extensions to the Path Computation Element Communication
Protocol (PCEP) for Route Exclusions", RFC 5521, April Protocol (PCEP) for Route Exclusions", RFC 5521, April
2009. 2009.
[RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, [RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku,
"Framework for GMPLS and PCE Control of Wavelength "Framework for GMPLS and PCE Control of Wavelength
Switched Optical Networks", RFC 6163, March 2011. Switched Optical Networks", RFC 6163, March 2011.
[RFC7446] Y. Lee, G. Bernstein. (Editors),"Routing and Wavelength [RFC6566] Lee, Y. and Berstein, G. (Editors), "A Framework for the
Control of Wavelength Switched Optical Networks (WSONs)
with Impairments", RFC 6566, March 2012.
[RFC7446] Y. Lee, G. Bernstein, (Editors), "Routing and Wavelength
Assignment Information Model for Wavelength Switched Assignment Information Model for Wavelength Switched
Optical Networks", RFC 7446, February 2015. Optical Networks", RFC 7446, February 2015.
[RFC7449] Y. Lee, G. Bernstein, (Editors), "Path Computation Element
Communication Protocol (PCEP) Requirements for Wavelength
Switched Optical Network (WSON) Routing and Wavelength
Assignment", RFC 7449, February 2015.
[RFC8253] D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody, "PCEPS: [RFC8253] D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody, "PCEPS:
Usage of TLS to Provide a Secure Transport for the Path Usage of TLS to Provide a Secure Transport for the Path
Computation Element Communication Protocol (PCEP)", RFC Computation Element Communication Protocol (PCEP)", RFC
8253, October 2017. 8253, October 2017.
[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.
11. Contributors 11. Contributors
Authors' Addresses
Young Lee, Editor
Huawei Technologies
1700 Alma Drive, Suite 100
Plano, TX 75075, USA
Phone: (972) 509-5599 (x2240)
Email: leeyoung@huawei.com
Ramon Casellas, Editor
CTTC PMT Ed B4 Av. Carl Friedrich Gauss 7
08860 Castelldefels (Barcelona)
Spain
Phone: (34) 936452916
Email: ramon.casellas@cttc.es
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
Germany Germany
skipping to change at line 1032 skipping to change at page 28, line 4
Madrid, 28043 Madrid, 28043
Spain Spain
Phone: +34 91 3374013 Phone: +34 91 3374013
Email: ogondio@tid.es Email: ogondio@tid.es
Greg Bernstein Greg Bernstein
Grotto Networking Grotto Networking
Fremont, CA, USA Fremont, CA, USA
Phone: (510) 573-2237 Phone: (510) 573-2237
Email: gregb@grotto-networking.com Email: gregb@grotto-networking.com
Authors' Addresses
Young Lee, Editor
Huawei Technologies
1700 Alma Drive, Suite 100
Plano, TX 75075, USA
Phone: (972) 509-5599 (x2240)
Email: leeyoung@huawei.com
Ramon Casellas, Editor
CTTC PMT Ed B4 Av. Carl Friedrich Gauss 7
08860 Castelldefels (Barcelona)
Spain
Phone: (34) 936452916
Email: ramon.casellas@cttc.es
 End of changes. 53 change blocks. 
119 lines changed or deleted 186 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/