Network Working Group Pierre Peloso
Internet Draft Alcatel-Lucent
Intended status: Standard Track Julien Meuric
Expires: September 2010 France Telecom
Giovanni Martinelli
Cisco
March 8, 2010
OSPF Extensions in support of O-E-O pools in GMPLS controlled all-
optical networks
draft-peloso-ccamp-wson-ospf-oeo-01.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 September 8, 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
Peloso and Meuric Expires September 8, 2010 [Page 1]
Internet-Draft OSPF Extensions for O-E-O in WSON March 2010
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
This document describes OSPF routing protocols extensions to support
blocking nodes and O-E-O pools in all-optical networks under the
control of Generalized MPLS (GMPLS).
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................................................2
2. O-E-O Pool Information.......................................3
2.1. Pool ID................................................5
2.2. Ingress/Egress Available Wavelength.....................5
2.3. Ingress/Egress O-E-O Features...........................5
3. Node Information............................................6
3.1. Connectivity Matrix.....................................6
3.2. Relation with O-E-O resources...........................6
4. Security Considerations......................................7
5. IANA Considerations.........................................7
5.1. Node Information........................................7
5.2. O-E-O Pool Information..................................7
6. References..................................................8
7. Author's Addresses..........................................9
Intellectual Property Statement.................................9
Disclaimer of Validity........................................10
1. Introduction
The goal of all-optical meshed networks consists in the transport of
optical circuit connections, with limited usage of Optical-
Electrical-Optical conversion through photonic nodes. The gain
brought by the use of fewer regenerators is balanced by the
constraint of maintaining the optical signal continuity between the
source and the destination nodes. In GMPLS controlled networks, the
induced signal continuity brings the technological challenge of
Peloso and Meuric Expires September 8, 2010 [Page 2]
Internet-Draft OSPF Extensions for O-E-O in WSON March 2010
wavelength assignment using control plane protocols, which is
discussed in [WSON-Frame].
The drawback of wavelength assignment computation in a single entity
is the need to gather and convey all relevant and up-to-date
information to this single entity. Whether the computing entity takes
the form of a PCE or the form of a Constrained-Shortest-Path-First
(C-SPF) engine in each node of the network, the IGP is supposed to do
the job of gathering this information.
Hence, this solution demands the flooding of a detailed view of the
network comprising more information than the usual topological ones,
[WSON-Info] and [WSON-encode] are addressing these concerns.
In order to complement this work and to extend the Traffic
Engineering (TE) properties of OSPF TE which are defined in
[RFC3630], [RFC4202], and [RFC4203], this draft proposes a layout of
information inside OSPF-TE LSAs. The TE LSA, is an opaque LSA with
one (at least) top-level TLV containing several sub-TLVs. The top-
level TLV can take one of five values (1) Router Address [RFC3630],
(2) Link [RFC3630], (3) Router IPv6 address [RFC5329], (4) Link Local
[RFC4203], (5) Node Attribute [OSPF-Node]. In this document, we
enhance the sub-TLVs for the Node Attribute TLV and we also introduce
a 6th type of top-level TLV, (6) O-E-O Pool Attribute.
The detailed encoding of OSPF extensions are not yet defined in this
document.
2. O-E-O Pool Information
This draft defines a new top-TLV named "O-E-O pool Attribute" TLV. It
carries attributes related to a pool of Optical-Electric-Optical
regeneration resource, thus allowing route computation to take into
account available signal regenerators in the network. Multiple O-E-O
resources are logically gathered in a pool when they share a common
transmission media before (and after) entering (exiting) the actual
switching matrix of the node. A common transmission media is
characterized by the sharing of at least a short section of fiber:
hence an amplifier or a wavelength selective switch does also
correspond to a common transmission media.
When several regenerators pools are available on a node, several "O-
E-O pool attribute" will be used (one for each pool). As a matter of
fact, the split into pools of the O-E-O resources comes from the
architectural structure of the node. This Node Attribute TLV contains
two or more sub-TLVs.
Peloso and Meuric Expires September 8, 2010 [Page 3]
Internet-Draft OSPF Extensions for O-E-O in WSON March 2010
The O-E-O pool information related to pools in WSON nodes include
Pool ID, lists of available wavelength on the ingress and egress side
of the pool, and the features of the O-E-O in the pool on the ingress
and egress side of the pool. These pieces of information are defined
in this document. The O-E-O pool information would also include some
sub-TLVs identical to sub-TLVs of the TE-link top-TLV: TE-metric
[rfc3630], Administrative Group [rfc3630], Link Local/Remote
Identifiers [rfc4203], Shared-Risk Link Group [rfc4203].
The following new sub-TLVs are added to the "O-E-O Pool Attribute"
TLV. Detailed description for newly defined sub-TLVs is provided at
the end of the section.
Sub-TLV Type Length Name
TBD 4 Bytes Pool ID
TBD variable Ingress Available Wavelength
TBD variable Egress Available Wavelength
TBD fixed Ingress O-E-O Features
TBD fixed Egress O-E-O Features
In "O-E-O Pool", the sub-TLVs "Ingress Available Wavelength" and
"Ingress O-E-O Features" are mandatory, the other sub-TLVs listed
above are optional. The omission of egress sub-TLV implies a symmetry
status of egress and ingress.
The following sub-TLVs to the "O-E-O Pool Attribute" TLV are
identical to the ones defined respectively in [RFC3630] and
[RFC4203], and being defined for the TE-link top-TLV. Detailed
description for newly defined sub-TLV is provided at the end of the
section.
Sub-TLV Type Length Name
TBD 4 Bytes TE-metric [alike RFC3630]
TBD 4 Bytes Administrative Group [alike RFC3630]
TBD 8 Bytes Link Local/Remote Identifiers [alike
RFC4203]
TBD variable Shared Risk Link Group [alike RFC4203]
Peloso and Meuric Expires September 8, 2010 [Page 4]
Internet-Draft OSPF Extensions for O-E-O in WSON March 2010
In "O-E-O Pool", the sub-TLV "Link Local/Remote Identifiers" is
mandatory as it is needed to ensure the consistency with the Node
Information described in Section 3. The other sub-TLVs listed above
are optional.
2.1. Pool ID
This optional sub-TLV can be used to provide an identifier to the
regenerator pool.
2.2. Ingress/Egress Available Wavelength
These sub-TLVs provide the list of available wavelength respectively
to reach the pool from the Node and to reach the Node from the pool
(meaning first before and second after the signal crosses the O-E-O).
These sub-TLVs share the same format as the Available Wavelength sub-
TLVs depicted in [WSON-Encode].
This sub-TLV is not depicting the switching constraints of the node
architecture, but the usage of some wavelengths by other resources in
the pool. Hence this sub-TLV is dynamic.
The omission of the egress sub-TLV is depicting a symmetrical usage
of wavelength on each side of the pool.
2.3. Ingress/Egress O-E-O Features
Both these sub-TLVs provide the features of a given O-E-O resource,
respectively on its incoming and on its outgoing side. The encoding
of this sub-TLV is not provided yet, but is likely to resemble
elements of [OSPF-signal-compatibility] and of Wavelength Converter
Range define in [WSON-encode]
Elements of the sub-TLVs:
. Signal Type: Modulation Format, Bit-Rate, Modulation parameters,
etc...
. Wavelength constraints: This is describing the wavelengths that
can actually be handled by the given equipment described by the
O-E-O Features instance, the form of this sub-sub-TLV would
probably be alike Wavelength Converter Range.
A given O-E-O piece of equipment is described by a pair of these sub-
TLVs (namely Ingress O-E-O Features followed by an Egress O-E-O
Features). Hence there will be an instance of such pairs for each O-
Peloso and Meuric Expires September 8, 2010 [Page 5]
Internet-Draft OSPF Extensions for O-E-O in WSON March 2010
E-O resource present in the pool, which shall in fine construct a
list of these sub-TLVs to describe the list of O-E-O resource.
The omission of the egress sub-TLV translates symmetry in the
features of the O-E-O on its ingress and on its egress side.
3. Node Information
The node information includes Node ID and Connectivity Matrix. The
Node ID should comply with Routing Address described in [RFC3630],
the Connectivity Matrix is defined in this document.
[OSPF-Node] defines a new top TLV named the Node Attribute TLV which
carries attributes related to a router/node. This Node Attribute TLV
contains one or more sub-TLVs. This draft introduces a new one which
description can be found at the end of the section:
Sub-TLV Type Length Name
TBD variable Connectivity Matrix
This TLV is optional. Usually this Connectivity Matrix sub-TLV would
appear in the LSA because the all-optical switches would present some
switching constraints (spatial and/or spectral). Omitting this sub-
TLV from the LSA would mean a fully flexible switch.
3.1. Connectivity Matrix
The Connectivity Matrix is a sub-TLV (the type is TBD by IANA) of the
Node Attribute TLV. The length is the length of value field in
octets. The meaning and format of this sub-TLV are defined in Section
4.3 of [WSON-Encode]. One sub-TLV contains one matrix. The
Connectivity Matrix sub-TLV may occur more than once to contain
multi-matrices within the Node Attribute TLV.
Note: Check that connectivity matrix uses interfaces references
consistent with Link Local/Remote Identifiers sub-TLV of the Top TLV
type 2 (Link) in order to ensure the consistency of the objects.
3.2. Relation with O-E-O resources
Accessing O-E-O pool is also subject to switching constraints. These
switching constraints can be both spatial and spectral.
In order to convey this information, the Connectivity Matrix sub-TLV
shall depict the ports of the O-E-O pool, and referring their Link
Local/Remote Identifiers sub-TLV as described in section 2.
Peloso and Meuric Expires September 8, 2010 [Page 6]
Internet-Draft OSPF Extensions for O-E-O in WSON March 2010
Hence the number of ports described by the connectivity matrix is:
# Ingress ports (CM): # incoming links (Node) + # O-E-O pools
# Egress ports (CM): # outgoing links (Node) + # O-E-O pools
4. Security Considerations
This document does not introduce any further security issues other
than those discussed in [RFC 3630], [RFC 4203].
5. IANA Considerations
[RFC3630] says that the top level Types in a TE LSA and Types for
sub-TLVs for each top level Types must be assigned by Expert Review,
and must be registered with IANA.
IANA is requested to allocate new Types for the sub-TLVs as defined
in Sections 2, 3, 3.1, 3.2 and 3.3 as follows:
5.1. Node Information
This document introduces the following sub-TLVs of Node Attribute TLV
(Value TBD, see [OSPF-Node])
Type sub-TLV
TBD Connectivity Matrix
TBD Wavelength Converter Accessibility
TBD Wavelength Conversion Range
TBD WC Usage State
5.2. O-E-O Pool Information
This document introduces the "O-E-O Pool Attribute" top-TLV, value
TBD with the following sub-TLVs:
Type Name
TBD Pool ID
TBD Ingress Available Wavelength
TBD Egress Available Wavelength
Peloso and Meuric Expires September 8, 2010 [Page 7]
Internet-Draft OSPF Extensions for O-E-O in WSON March 2010
TBD Ingress O-E-O Features
TBD Egress O-E-O Features
TBD TE-metric [alike RFC3630]
TBD Administrative Group [alike RFC3630]
TBD Link Local/Remote Identifiers [alike RFC4203]
TBD Shared Risk Link Group [alike RFC4203]
6. 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.
[RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4202, October 2005
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC
4203, October 2005.
[RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF-Node] R. Aggarwal and K. Kompella, "Advertising a Router's
Local Addresses in OSPF TE Extensions", draft-ietf-ospfte-node-addr,
work in progress.
[WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS
and PCE Control of Wavelength Switched Optical Networks", work in
progress: draft-ietf-ccamp-rwa-WSONFramework-04.txt, October 2009.
[WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and
Wavelength Assignment Information Model for Wavelength Switched
Peloso and Meuric Expires September 8, 2010 [Page 8]
Internet-Draft OSPF Extensions for O-E-O in WSON March 2010
Optical Networks", work in progress: draft-ietfccamp-rwa-info-05.txt,
October 2009.
[WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and
Wavelength Assignment Information Encoding for Wavelength Switched
Optical Networks", work in progress: draft-ietf-ccamp-rwa-wson-
encode-03.txt, October 2009.
7. Author's Addresses
Peloso Pierre
Alcatel-Lucent
Rte de Villejust
91620 Nozay, France
Phone: +33 130 702 662
Email: pierre.peloso@alcatel-lucent.com
Julien Meuric
France Telecom
2, av Pierre Marzin
22307 Lannion Cedex, France
Phone: +33 296 052 828
Email: julien.meuric@orange-ftgroup.com
Giovanni Martinelli
Cisco
Via Philips 12
20052 Monza, Italy
Phone: +39 039 2092044
Email: giomarti@cisco.com
Intellectual Property Statement
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Peloso and Meuric Expires September 8, 2010 [Page 9]
Internet-Draft OSPF Extensions for O-E-O in WSON March 2010
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.
Peloso and Meuric Expires September 8, 2010 [Page 10]