Network Working Group Y. Lee
Internet Draft Huawei
Intended status: Standards Track G. Bernstein
Expires: March 2012 Grotto Networking
September 14, 2011
GMPLS OSPF Enhancement for Signal and Network Element Compatibility
for Wavelength Switched Optical Networks
draft-ietf-ccamp-wson-signal-compatibility-ospf-06.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 March 14, 2007.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Lee and Bernstein Expires March 14, 2012 [Page 1]
Internet-Draft OSPF Enhancement for WSON Signal Compatibility September
2011
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 document provides GMPLS OSPF routing enhancements to support
signal compatibility constraints associated with WSON network
elements. These routing enhancements are required in common optical
or hybrid electro-optical networks where not all of the optical
signals in the network are compatible with all network elements
participating in the network.
This compatibility constraint model is applicable to common optical
or hybrid electro optical systems such as OEO switches, regenerators,
and wavelength converters since such systems can be limited to
processing only certain types of WSON signals.
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 [RFC2119].
Table of Contents
1. Introduction...................................................3
1.1. Revision History..........................................3
2. The Optical Node Property TLV..................................4
2.1. Sub-TLV Details...........................................5
2.1.1. Resource Block Information...........................5
2.1.2. Resource Pool Accessibility..........................6
2.1.3. Resource Block Wavelength Constraints................6
2.1.4. Resource Pool State..................................6
2.1.5. Block Shared Access Wavelength Availability..........6
3. WSON Specific Scalability and Timeliness.......................7
3.1. Different Sub-TLVs into Multiple LSAs.....................7
3.2. Separating a Sub-TLV into Multiple LSAs...................8
Lee and Bernstein Expires March 14, 2012 [Page 2]
Internet-Draft OSPF Enhancement for WSON Signal Compatibility September
2011
3.2.1. Sub-Division by Sets.................................8
3.2.2. Sub-Division by Options..............................9
4. Security Considerations.......................................10
5. IANA Considerations...........................................10
6. References....................................................12
6.1. Normative References.....................................12
7. Authors and Contributors......................................13
Authors' Addresses...............................................13
Intellectual Property Statement..................................14
Disclaimer of Validity...........................................14
1. Introduction
The documents [RFC6163, WSON-Info, WSON-Encode] explain how to extend
the wavelength switched optical network (WSON) control plane to allow
both multiple WSON signal types and common hybrid electro optical
systems as well hybrid systems containing optical switching and
electro-optical resources. In WSON, not all of the optical signals in
the network are compatible with all network elements participating in
the network. Therefore, signal compatibility is an important
constraint in path computation in a WSON.
This document provides GMPLS OSPF routing enhancements to support
signal compatibility constraints associated with general WSON network
elements. These routing enhancements are required in common optical
or hybrid electro-optical networks where not all of the optical
signals in the network are compatible with all network elements
participating in the network.
This compatibility constraint model is applicable to common optical
or hybrid electro optical systems such as OEO switches, regenerators,
and wavelength converters since such systems can be limited to
processing only certain types of WSON signals.
1.1. Revision History
From 00 to 01: The details of the encodings for compatibility moved
from this document to [WSON-Encode].
From 01 to 02: Editorial changes.
From 02 to 03: Add a new Top Level Node TLV, Optical Node Property
TLV to carry WSON specific node information.
Lee and Bernstein Expires March 14, 2012 [Page 3]
Internet-Draft OSPF Enhancement for WSON Signal Compatibility September
2011
From 03 to 04: Add a new sub-TLV, Block Shared Access Wavelength
Availability TLV to be consistent with [WSON-Encode] and editorial
changes.
From 04 to 05: Add a new section that discusses OSPF scalability and
timeliness and editorial changes.
From 05 to 06: Change the title of the draft to "GMPLS OSPF
Enhancement" from "OSPF Enhancement" to make sure the changes apply
to the GMPLS OSPF rather than the base OSPF. Add specific OSPF
procedures on how sub-TLVs are packaged per [RFC3630] and editorial
changes.
2. The Optical Node Property TLV
[RFC3630] defines OSPF TE LSA using an opaque LSA. This document adds
a new top level TLV for use in the OSPF TE LSA: the Optical Node
Property TLV. The Optical Node property TLV describes a single node.
It is constructed of a set of sub-TLVs. There are no ordering
requirements for the sub-TLVs. Only one Optical Node TLV shall be
advertised in each LSA.
The Optical Node Property TLV contains all WSON-specific node
properties and signal compatibility constraints. The detailed
encodings of these properties are defined in [WSON-Encode].
The following sub-TLVs of the Optical Node Property TLV are defined:
Value Length Sub-TLV Type
TBA variable Resource Block Information
TBA variable Resource Pool Accessibility
TBA variable Resource Block Wavelength Constraints
TBA variable Resource Pool State
TBA variable Block Shared Access Wavelength Availability
The detail encodings of these sub-TLVs are found in [WSON-Encode] as
indicated in the table below.
Lee and Bernstein Expires March 14, 2012 [Page 4]
Internet-Draft OSPF Enhancement for WSON Signal Compatibility September
2011
Sub-TLV Type Section [WSON-Encode]
Resource Block Information 4.1
Resource Pool Accessibility 3.1
Resource Block Wavelength Constraints 3.2
Resource Pool State 3.3
Block Shared Access Wavelength Availability 3.4
All sub-TLVs defined here may occur at most once in any given Optical
Node TLV. These restrictions need not apply to future sub-TLVs.
Unrecognized sub-TLVs are ignored.
2.1. Sub-TLV Details
Among the sub-TLVs defined above, the Resource Pool State sub-TLV and
Block Shared Access Wavelength Availability are dynamic in nature
while the rest are static. As such, they can be separated out from
the rest and be advertised with multiple TE LSAs per OSPF router, as
described in [RFC3630] and [RFC5250].
2.1.1. Resource Block Information
Resource Block Information sub-TLVs are used to convey relatively
static information about individual resource blocks including the
resource block properties and the number of resources in a block.
There are seven nested sub-TLVs defined in the Resource Block
Information sub-TLV.
Value Length Sub-TLV Type
TBA variable Input Modulation Format List
TBA variable Input FEC Type List
TBA variable Input Bit Range List
TBA variable Input Client Signal List
TBA variable Processing Capability List
TBA variable Output Modulation Format List
TBA variable Output FEC Type List
Lee and Bernstein Expires March 14, 2012 [Page 5]
Internet-Draft OSPF Enhancement for WSON Signal Compatibility September
2011
The detail encodings of these sub-TLVs are found in [WSON-Encode] as
indicated in the table below.
Name Section [WSON-Encode]
Input Modulation Format List 4.2
Input FEC Type List 4.3
Input Bit Range List 4.4
Input Client Signal List 4.5
Processing Capability List 4.6
Output Modulation Format List 4.7
Output FEC Type List 4.8
2.1.2. Resource Pool Accessibility
This sub-TLV describes the structure of the resource pool in relation
to the switching device. In particular it indicates the ability of an
ingress port to reach a resource block and of a resource block to
reach a particular egress port.
2.1.3. Resource Block Wavelength Constraints
Resources, such as wavelength converters, etc., may have a limited
input or output wavelength ranges. Additionally, due to the structure
of the optical system not all wavelengths can necessarily reach or
leave all the resources. Resource Block Wavelength Constraints sub-
TLV describe these properties.
2.1.4. Resource Pool State
This sub-TLV describes the usage state of a resource that can be
encoded as either a list of 16 bit integer values or a bit map
indicating whether a single resource is available or in use. This
information can be relatively dynamic, i.e., can change when a
connection is established or torn down.
2.1.5. Block Shared Access Wavelength Availability
Resources blocks may be accessed via a shared fiber. If this is the
case then wavelength availability on these shared fibers is needed to
understand resource availability.
Lee and Bernstein Expires March 14, 2012 [Page 6]
Internet-Draft OSPF Enhancement for WSON Signal Compatibility September
2011
3. WSON Specific Scalability and Timeliness
This document has defined five sub-TLVs specific to WSON. The
examples given in [WSON-Encode] show that very large systems, in
terms of channel count, ports, or resources, can be very efficiently
encoded. However there has been concern expressed that some possible
systems may produce LSAs that exceed the IP Maximum Transmission Unit
(MTU) and that methods be given to allow for the splitting of WSON
specific LSA into smaller LSA that are under the MTU limit. This
section presents a set of techniques that can be used for this
purpose.
3.1. Different Sub-TLVs into Multiple LSAs
Five sub-TLVs are defined in this document:
1. Resource Block Information
2. Resource Pool Accessibility
3. Resource Block Wavelength Constraints
4. Resource Pool State
5. Block Shared Access Wavelength Availability
All these are carried in an Optical Node Property TLV (see Section 2
for detail) of which there can be at most one in an LSA. Of these
sub-TLVs the first three are relatively static, i.e., only would
change with hardware changes or significant system reconfiguration.
While the fourth and fifth are dynamic, meaning that they may change
with LSP setup or teardown through the system. The most important
technique for scalability and OSPF bandwidth reduction is to separate
the dynamic information sub-TLVs from the static information sub-TLVs
and advertise them in OSPF TE LSAs, each with the Optical Node
Property TLV at the top level ([RFC3630 and RFC5250]).
For LSA overhead reduction it is recommended to group as many of the
three static sub-TLVs into the same LSA (within the Optical Node
Property TLV). If the size of this LSA is greater than the MTU, then
these sub-TLV can be packed into separate LSAs. From the point of
view of path computation, the presence of the Resource Block
Information sub-TLV indicates that resources exist in the system and
may have signal compatibility or other constraints. The other four
sub-TLVs indicate constraints on access to, and availability of those
resources.
Lee and Bernstein Expires March 14, 2012 [Page 7]
Internet-Draft OSPF Enhancement for WSON Signal Compatibility September
2011
Hence the "synchronization" procedure from a path computation point
of view is quite simple. Until a Resource Block Information sub-TLV
is received for a system path cannot make use of the other four sub-
TLVs since it does not know the nature of the resources, e.g., are
the resources wavelength converters, regenerators, or something else.
Once this sub-TLV is received path computation can proceed with
whatever of the additional types of sub-TLVs it may have received
(there use is dependent upon the system type). If path computation
proceeds with out of date or missing information from these sub-TLVs
then there is the possibility of either (a) path computation
computing a path that does not exist in the network, (b) path
computation failing to find a path through the network that actually
exists. Both situations are currently encountered with GMPLS, i.e.,
out of date information on constraints or resource availability.
Note that the connection establishment mechanism (signaling or
management) is ultimately responsible for the establishment of the
connection, and this implies that such mechanisms must insure signal
compatibility.
3.2. Separating a Sub-TLV into Multiple OSPF TE LSAs
In the highly unlikely event that a WSON sub-TLV by itself would
result in an LSA exceeding the MTU, all five WSON specific sub-TLVs
in this document provide mechanisms that allow them to be subdivided
into smaller sub-TLVs that can be sent in separate OSPF TE LSAs.
Sub-Division by Sets
All five sub-TLVs currently make use of one or more RB Set Fields
[WSON-Encode] or Link Set Fields [Gen-Encode]. Long set fields can be
decomposed into multiple smaller set fields resulting in multiple
sub-TLVs that can be sent in multiple OSPF TE LSAs. The
interpretation of the separate pieces is quite natural and reviewed
in the following:
Lee and Bernstein Expires March 14, 2012 [Page 8]
Internet-Draft OSPF Enhancement for WSON Signal Compatibility September
2011
Resource Block Information
Information about different resources of similar types would get
sent separately (LSAs). Path computation would not know a resource
exists until it receives the instance of a sub-TLV that mentions
that instance.
Resource Pool Accessibility
Information about accessibility to resources to/from ports would be
in as separate pieces base on port or resource set separation. All
pieces are combined to give complete resource/port accessibility
view. Late/missing pieces would imply resources are not accessible
to/from given ports.
Resource Block Wavelength Constraints
Information about resource wavelength constraints can be sent in
separate pieces based on resource sub-sets. Late/missing pieces
(LSAs) would imply resources accessible when they might not be.
Resource Pool State
Information about resource state can be sent in separate pieces
based on resource sub-sets. Late/missing pieces (LSAs) could imply
incorrect resources availability.
Block Shared Access Wavelength Availability
Information about resource shared access wavelength can be sent in
separate pieces based on resource sub-sets. Late/missing pieces
(LSAs) could imply incorrect shared wavelength availability.
Due to the reliability mechanisms in OSPF the phenomena of late or
missing pieces for relatively static information (first three types
of sub-TLVs) would be relatively rare.
3.2.1. Sub-Division by Options
The Resource Block Information sub-TLV contains a number of optional
fields. If this sub-TLV becomes too long it may also be sub-divided
into multiple OSPF TE LSAs each containing a disjoint assembly of the
sub-TLVs optional fields [WSON-Encode].
Lee and Bernstein Expires March 14, 2012 [Page 9]
Internet-Draft OSPF Enhancement for WSON Signal Compatibility September
2011
4. Security Considerations
This document does not introduce any further security issues other
than those discussed in [RFC3630], [RFC4203].
5. IANA Considerations
This document introduces a new Top Level Node TLV (Optical Node
Property TLV) under the OSPF TE LSA defined in [RFC3630].
Value TLV Type
TBA Optical Node Property
IANA is to allocate a new TLV Type and its Value for this Top Level
Node TLV.
This document also introduces the following sub-TLVs associated with
the Optical Node Property TLV as defined in Section 2.1 as follows:
Value Length Sub-TLV Type
TBA variable Resource Block Information
TBA variable Resource Pool Accessibility
TBA variable Resource Block Wavelength Constraints
TBA variable Resource Pool State
TBA variable Block Shared Access Wavelength Availability
IANA is to allocate new sub-TLV Types and their Values for these sub-
TLVs defined under the Optical Node Property TLV.
There are seven nested sub-TLVs defined in the Resource Block
Information sub-TLV as follows:
Value Length Sub-TLV Type
TBA variable Input Modulation Format List
TBA variable Input FEC Type List
TBA variable Input Bit Range List
TBA variable Input Client Signal List
TBA variable Processing Capability List
TBA variable Output Modulation Format List
Lee and Bernstein Expires March 14, 2012 [Page 10]
Internet-Draft OSPF Enhancement for WSON Signal Compatibility September
2011
TBA variable Output FEC Type List
IANA is to allocate new Sub-TLV Types and their Values for these Sub-
TLVs defined under the Resource Block Information Sub-TLV.
Lee and Bernstein Expires March 14, 2012 [Page 11]
Internet-Draft OSPF Enhancement for WSON Signal Compatibility September
2011
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM
applications: DWDM frequency grid", June, 2002.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005.
[WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and
Wavelength Assignment Information Encoding for Wavelength
Switched Optical Networks", draft-ietf-ccamp-rwa-wson-
encode, work in progress.
[Gen-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "General
Network Element Constraint Encoding for GMPLS Controlled
Networks", draft-ietf-ccamp-general-constraint-encode,
work in progress.
6.2. Informative References
[WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and
Wavelength Assignment Information Model for Wavelength
Switched Optical Networks", draft-ietf-ccamp-rwa-info, work
in progress.
[RFC6250] T. Otani, Ed., D. Li, Ed., "Generalized Labels for G.694
Lambda-Switching Capable Label Switching Routers", RFC
6250, March 2011.
Lee and Bernstein Expires March 14, 2012 [Page 12]
Internet-Draft OSPF Enhancement for WSON Signal Compatibility September
2011
[RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and
PCE Control of Wavelength Switched Optical Networks", RFC
6163, April 2011.
[RFC5250] Berger, L., et al., "The OSPF Opauqe LSA option", RFC 5250,
July 2008.
7. Authors and Contributors
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 M. Bernstein (ed.)
Grotto Networking
Fremont California, USA
Phone: (510) 573-2237
Email: gregb@grotto-networking.com
Lee and Bernstein Expires March 14, 2012 [Page 13]
Internet-Draft OSPF Enhancement for WSON Signal Compatibility September
2011
Intellectual Property Statement
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lee and Bernstein Expires March 14, 2012 [Page 14]
