Network Working Group Y. Lee
Internet Draft Huawei
Intended status: Standard Track
Expires: April 2011 G. Bernstein
Grotto Networking
Jonas Martensson
Acreo
T. Tsuritani
KDDI
Oscar Gonzalez de Dios
Telefonica
October 22, 2010
PCEP Extensions in support of WSON Signal Compatibility Constraints
draft-lee-pce-wson-signal-compatibility-03.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 22, 2009.
Lee & Bernstein Expires April 22, 2011 [Page 1]
Internet-Draft PCEP Extension for WSON RWA October 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
This memo provides the Path Computation Element communication
Protocol (PCEP) extensions for the support of signal compatibility
constraints in Wavelength Switched Optical Networks (WSON).
Signal compatibility is an essential path computation constraint in
path computation of WSON networks where network elements can be
limited to processing WSON signals with specific characteristics and
attributes.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 0.
Table of Contents
1. Introduction...................................................3
2. PCEP Requirements..............................................4
3. PCEP Extensions (Encoding).....................................5
3.1. The PCC to PCE Interface..................................5
3.1.1. Signal Compatibility Indicator in the RP Object in the
PC Request Message..........................................5
3.1.2. Modulation Type List sub-TLV.........................5
3.1.3. Channel Spacing sub-TLV..............................7
3.1.4. FEC Type List sub-TLV................................8
3.1.5. The GPID Type Sub-TLV...............................11
Lee Expires April 22, 2011 [Page 2]
Internet-Draft PCEP Extension for WSON RWA October 2010
3.2. The PCE to PCC Interface.................................11
3.2.1. Modulation Type sub-TLV.............................12
3.2.2. FEC Type sub-TLV....................................12
3.2.3. Regeneration Point sub-TLV..........................12
4. Manageability Considerations..................................13
5. Security Considerations.......................................13
6. IANA Considerations...........................................13
7. Acknowledgments...............................................13
8. References....................................................14
8.1. Normative References.....................................14
8.2. Informative References...................................14
Authors' Addresses...............................................15
Intellectual Property Statement..................................16
Disclaimer of Validity...........................................16
1. Introduction
[RFC4655] defines the PCE based Architecture and explains how a Path
Computation Element (PCE) may compute Label Switched Paths (LSP) in
Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and
Generalized MPLS (GMPLS) networks at the request of Path Computation
Clients (PCCs). A PCC is shown to be any network component that
makes such a request and may be for instance an Optical Switching
Element within a Wavelength Division Multiplexing (WDM) network. The
PCE, itself, can be located anywhere within the network, and may be
within an optical switching element, a Network Management System
(NMS) or Operational Support System (OSS), or may be an independent
network server.
The PCE communications Protocol (PCEP) is the communication protocol
used between PCC and PCE, and may also be used between cooperating
PCEs. [RFC4657] sets out the common protocol requirements for PCEP.
Additional application-specific requirements for PCEP are deferred to
separate documents.
This document provides the Path Computation Element communication
Protocol (PCEP) extensions for the support of signal compatibility
constraints in Wavelength Switched Optical Networks (WSON). Signal
compatibility is an essential path computation constraint in path
computation of WSON networks where network elements can be limited to
processing WSON signals with specific characteristics and attributes.
Signals used in a WSON are not always compatible with common network
elements including regenerators, OEO switches, wavelength converters,
etc. [WSON-Frame] defines the GMPLS control plane framework that
Lee Expires April 22, 2011 [Page 3]
Internet-Draft PCEP Extension for WSON RWA October 2010
allows both multiple WSON signal types and common hybrid electro
optical systems. Reference [WSON-Frame] characterizes WSON signals in
line with ITU-T standards, and adds attributes describing signal
compatibility constraints to WSON network elements.
[CompatOSPF] provides GMPLS OSPF routing enhancements to support
signal compatibility constraints associated with WSON network
elements. On a high-level the following network element information
would be required for the path computation element (PCE) to be able
to compute a constrained path that satisfies signal compatibility and
processing constraints:
. Input Compatibility: the type of signals it can receive
(modulation types, Channel Spacing, FEC types)
. Regeneration Capability: the types of processing/enhancement
it can perform (1R, 2R, 3R)
. The types of conversions it can perform (modulation types, FEC
types)
. Output Format: the type of signals it can transmit (modulation
types, Channel Spacing, FEC types)
2. PCEP Requirements
This section provides a set of PCEP requirements to support signal
compatibility constraints.
When requesting a path computation (PCReq) to PCE, the PCC should be
able to indicate the following:
o The acceptable signal attributes at the transmitter (at the
source): (i) Modulation types; (ii) Channel Spacing; (iii) FEC
types
o The acceptable signal attributes at the receiver (at the sink):
(i) Modulation types; (ii) Channel Spacing; (iii) FEC types
o The ability to specify if regeneration is allowed in the computed
path; if allowed, the maximum number of regenerators allowed in
the computed path should be indicated.
Lee Expires April 22, 2011 [Page 4]
Internet-Draft PCEP Extension for WSON RWA October 2010
The PCE should be able to respond (PC Rep) to the PCC with the
following:
o The conformity of the requested optical characteristics associated
with the resulting LSP with the source, sink and Network Element
(NE) along the LSP.
o Additional LSP attributes modified along the path (e.g.,
modulation format change, etc.)
o Special node processing with the resulting LSP (e.g., regeneration
point)
3. PCEP Extensions (Encoding)
This section provides PCEP encoding to support the identified
requirements in Section 2.
3.1. The PCC to PCE Interface
This section provides the enhancements to the Request Parameter (RP)
Object and its associated sub-TLV in the PC Request message from the
PCC to the PCE interface to support signal compatibility constraints.
3.1.1. Signal Compatibility Indicator in the RP Object in
the PC Request Message
The RP object should have a bit indicating that signal compatibility
check (say SC bit) should be performed for a path computation.
3.1.2. Modulation Type List sub-TLV
When the SC bit in the RP Object is set to 1, then the RP object
should include the Modulation Type List TLV associated with the
request. Modulation types listed in the Modulation Type List TLV
indicate allowable modulation types in both the source (transmitter)
and the sink (receiver).
The modulation type list sub-TLV may consist of two different types
of fields: a standard modulation field or a vendor specific
modulation field. Both start with the same 32 bit header shown below.
Lee Expires April 22, 2011 [Page 5]
Internet-Draft PCEP Extension for WSON RWA October 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|I| Modulation ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where S bit set to 1 indicates a standardized modulation format and S
bit set to 0 indicates a vendor specific modulation format. The
length is the length in bytes of the entire modulation type field.
Where I bit set to 1 indicates an input modulation format and where I
bit set to 0 indicates an output modulation format. Note that the
source modulation type is implied when I bit is set to 0 and that the
sink modulation type is implied when I bit is set to 1.
The format for the standardized type for the input modulation at the
sink is given by:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Modulation ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Possible additional modulation parameters depending upon |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: the modulation ID :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Modulation ID
Takes on the following currently defined values:
0 Reserved
1 optical tributary signal class NRZ 1.25G
2 optical tributary signal class NRZ 2.5G
3 optical tributary signal class NRZ 10G
4 optical tributary signal class NRZ 40G
5 optical tributary signal class RZ 40G
Lee Expires April 22, 2011 [Page 6]
Internet-Draft PCEP Extension for WSON RWA October 2010
Note that future modulation types may require additional parameters
in their characterization.
The format for vendor specific input modulation field at the sink is
given by:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Vendor Modulation ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Any vendor specific additional modulation parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor Modulation ID
This is a vendor assigned identifier for the modulation type.
Enterprise Number
A unique identifier of an organization encoded as a 32-bit integer.
Enterprise Numbers are assigned by IANA and managed through an IANA
registry [RFC2578].
Vendor Specific Additional parameters
There can be potentially additional parameters characterizing the
vendor specific modulation.
3.1.3. Channel Spacing sub-TLV
When the SC bit in the RP Object is set to 1, then the RP object
should include the Channel Spacing Type List TLV associated with the
request. Spacing types listed in the Channel Spacing Type List TLV
indicate allowable Channel Spacing types in both source (transmitter)
and the sink (receiver).
The format for the channel spacing field is given by:
Lee Expires April 22, 2011 [Page 7]
Internet-Draft PCEP Extension for WSON RWA October 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Spacing ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Channel Spacing ID
Takes on the following currently defined values:
0 Reserved
1 100 GHz
2 50 GHz
3 25 GHz
4 12.5 GHz
5-15 Future Use
3.1.4. FEC Type List sub-TLV
When the SC bit in the RP Object is set to 1, then the RP object
should include the FEC Type List TLV associated with the request. FEC
types listed in the FEC Type List TLV indicate allowable FEC types in
both the source (transmitter) and the sink (receiver).
The FEC type list sub-TLV may consist of two different types of
fields: a standard FEC field or a vendor specific FEC field. Both
start with the same 32 bit header shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|I| FEC ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Possible additional FEC parameters depending upon |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: the FEC ID :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lee Expires April 22, 2011 [Page 8]
Internet-Draft PCEP Extension for WSON RWA October 2010
Where S bit set to 1 indicates a standardized FEC format and S bit
set to 0 indicates a vendor specific FEC format.
Where the length is the length in bytes of the entire FEC type field.
Where I bit set to 1 indicates an input FEC format and where I bit
set to 0 indicates an output FEC format. Note that the source FEC
type is implied when I bit is set to 0 and that the sink FEC type is
implied when I bit is set to 1.
The format for input standard FEC field at the sink is given by:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| FEC ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Possible additional FEC parameters depending upon |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: the FEC ID :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Takes on the following currently defined values for the standard
FEC ID:
0 Reserved
1 G.709 RS FEC
2 G.709V compliant Ultra FEC
3 G.975.1 Concatenated FEC
(RS(255,239)/CSOC(n0/k0=7/6,J=8))
4 G.975.1 Concatenated FEC (BCH(3860,3824)/BCH(2040,1930))
5 G.975.1 Concatenated FEC (RS(1023,1007)/BCH(2407,1952))
6 G.975.1 Concatenated FEC (RS(1901,1855)/Extended Hamming
Product Code (512,502)X(510,500))
7 G.975.1 LDPC Code
Lee Expires April 22, 2011 [Page 9]
Internet-Draft PCEP Extension for WSON RWA October 2010
8 G.975.1 Concatenated FEC (Two orthogonally concatenated
BCH codes)
9 G.975.1 RS(2720,2550)
10 G.975.1 Concatenated FEC (Two interleaved extended BCH
(1020,988) codes)
Where RS stands for Reed-Solomon and BCH for Bose-Chaudhuri-
Hocquengham.
The format for input vendor-specific FEC field at the sink is given
by:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Vendor FEC ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Any vendor specific additional FEC parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor FEC ID
This is a vendor assigned identifier for the FEC type.
Enterprise Number
A unique identifier of an organization encoded as a 32-bit integer.
Enterprise Numbers are assigned by IANA and managed through an IANA
registry [RFC2578].
Vendor Specific Additional FEC parameters
There can be potentially additional parameters characterizing the
vendor specific FEC.
Lee Expires April 22, 2011 [Page 10]
Internet-Draft PCEP Extension for WSON RWA October 2010
3.1.5. The GPID Type Sub-TLV
When the SC bit in the RP Object is set to 1, then the RP object
should include the GPID Type sub-TLV with the path request. The GPID
Type should be one of Generalized Protocol Identifiers (GPIDs). GPIDs
are assigned by IANA and many are defined in [RFC3471] and [RFC4328].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where GPID is an identifier encoded as a 32-bit integer.
3.2. The PCE to PCC Interface
This section provides the enhancements to the RP Object and its
associated sub-TLV in the PC Reply message from the PCE to the PCC
interface to support signal compatibility constraints.
The PCE MUST specify the detail signal compatibility information in
response to the "SC" (Signal Compatibility) request made by the PCC.
The ERO object in the PC Rep message SHOULD include the following
sub-TLV if the SC-bit is set in the RP object in the PC Req message:
o Modulation Type sub-TLV
o FEC Type sub-TLV
o Regeneration Point sub-TLV
Note that each of the TLV defined above would be in an ERO as
subobjects placed after the node identifier (IP address).
In addition, the PC Rep message SHOULD specify a list of
Modulation/FEC types (per node identifier) in the ERO object in the
case when more than one is compatible with all constraints.
Lee Expires April 22, 2011 [Page 11]
Internet-Draft PCEP Extension for WSON RWA October 2010
3.2.1. Modulation Type sub-TLV
The modulation type sub-TLV indicates the output modulation type
associated with the node identifier. It starts with the same 32 bit
header shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modulation ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.2. FEC Type sub-TLV
The FEC type sub-TLV indicates the output FEC type associated with
the node identifier. It starts with the same 32 bit header shown
below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.3. Regeneration Point sub-TLV
The Regeneration Point sub-TLV indicates this particular node is a
regeneration point.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T | C | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where T bit indicates the type of regenerator:
T=0: Reserved
T=1: 1R Regenerator
T=2: 2R Regenerator
Lee Expires April 22, 2011 [Page 12]
Internet-Draft PCEP Extension for WSON RWA October 2010
T=3: 3R Regenerator
Where C bit indicates the capability of regenerator:
C=0: Reserved
C=1: Fixed Regeneration Point
C=2: Selective Regeneration Pools
Note that when the capability of regenerator is indicated to be
Selective Regeneration Pools, regeneration pool properties such as
ingress and egress restrictions and availability need to be
specified. This encoding is to be determined in the later revision.
4. Manageability Considerations
This document does not add additional manageability considerations.
5. Security Considerations
This document has no requirement for a change to the security models
within PCEP [PCEP]. However the additional information distributed in
order to address the RWA problem represents a disclosure of network
capabilities that an operator may wish to keep private. Consideration
should be given to securing this information.
6. IANA Considerations
A future revision of this document will present requests to IANA for
codepoint allocation.
7. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Lee Expires April 22, 2011 [Page 13]
Internet-Draft PCEP Extension for WSON RWA October 2010
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657,
September 2006.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) communication Protocol (PCEP) - Version 1",
RFC 5440, March 2009.
[CompatOSPF] Lee, Y. and Bernstein, G., "OSPF Enhancement for Signal
and Network Element Compatibility for Wavelength Switched
Optical Networks", draft-lee-ccamp-wson-signal-
compatibility-ospf, work in progress.
8.2. Informative References
[WSON-IMP] Lee, Y. and Bernstein, G. (Editors), D. Li, G. Martinelli,
"A Framework for the Control of Wavelength Switched Optical
Networks (WSON) with Impairments", draft-ietf-ccamp-wson-
impairments, work in progress.
[WSON-Frame] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku,
"Framework for GMPLS and PCE Control of Wavelength Switched
Optical Networks", draft-ietf-ccamp-rwa-wson-framework,
work in progress.
Lee Expires April 22, 2011 [Page 14]
Internet-Draft PCEP Extension for WSON RWA October 2010
[CompatOSPF] Lee, Y. and Berstein, G. (Editors), J. Martensson, and
Takehiro Tsuritani, "OSPF Enhancement for Signal and
Network Element Compatibility for Wavelength Switched
Optical Networks", draft-ietf-ccamp-wson-signal-
compatibility-ospf, work in progress.
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "OSPF Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, January 2008.
[G.709] ITU-T Recommendation G.709, Interfaces for the Optical
Transport Network(OTN), March 2003.
[G.975.1] ITU-T Recommendation G.975.1, Forward error correction for
high bit-rate DWDM submarine systems, February, 2004.
Authors' Addresses
Young Lee (Ed.)
Huawei Technologies
1700 Alma Drive, Suite 100
Plano, TX 75075, USA
Phone: (972) 509-5599 (x2240)
Email: ylee@huawei.com
Greg Bernstein (Ed.)
Grotto Networking
Fremont, CA, USA
Phone: (510) 573-2237
Email: gregb@grotto-networking.com
Jonas Martensson
Acreo
Email:Jonas.Martensson@acreo.se
Lee Expires April 22, 2011 [Page 15]
Internet-Draft PCEP Extension for WSON RWA October 2010
Takehiro Tsuritani
2-1-15 Ohara, Fujimino, Saitama, 356-8502, JAPAN
KDDI R&D Laboratories Inc.
Phone: +81-49-278-7806
Email: tsuri@kddilabs.jp
Oscar Gonzalez de Dios
Telefonica
Email : ogondio@tid.es
Intellectual Property Statement
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Lee Expires April 22, 2011 [Page 16]
Internet-Draft PCEP Extension for WSON RWA October 2010
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lee Expires April 22, 2011 [Page 17]