Network Working Group Pierre Peloso Internet Draft Alcatel-Lucent Intended status: Standard Track Expires: September 2010 Julien Meuric France Telecom March 1, 2010 OSPF Extensions in support of O-E-O pools in GMPLS controlled all- optical networks draft-peloso-ccamp-wson-ospf-oeo-00.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 1, 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 1, 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. Node Information............................................3 3. O-E-O Pool Information.......................................4 3.1. Pool ID................................................5 3.2. Ingress/Egress Available Wavelength.....................5 3.3. Ingress/Egress O-E-O Features...........................5 4. Security Considerations......................................6 5. IANA Considerations.........................................6 5.1. Node Information........................................6 5.2. O-E-O Pool Information..................................6 6. References..................................................7 7. Author's Addresses..........................................8 Intellectual Property Statement.................................8 Disclaimer of Validity.........................................9 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 wavelength assignment using control plane protocols, which is discussed in [WSON-Frame]. Peloso and Meuric Expires September 1, 2010 [Page 2] Internet-Draft OSPF Extensions for O-E-O in WSON March 2010 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. 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. 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 Peloso and Meuric Expires September 1, 2010 [Page 3] Internet-Draft OSPF Extensions for O-E-O in WSON March 2010 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. 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. This Node Attribute TLV contains one or more sub-TLVs. 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. Peloso and Meuric Expires September 1, 2010 [Page 4] Internet-Draft OSPF Extensions for O-E-O in WSON March 2010 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] 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 2. The other sub-TLVs listed above are optional. 3.1. Pool ID This optional sub-TLV can be used to provide an identifier to the regenerator pool. 3.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]. The omission of the egress sub-TLV is depicting a symmetrical usage of wavelength on each side of the pool. 3.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: Peloso and Meuric Expires September 1, 2010 [Page 5] Internet-Draft OSPF Extensions for O-E-O in WSON March 2010 . Signal Type: Modulation Format, Bit-Rate, Modulation parameters, etc... . Wavelength constraints: (alike Wavelength Converter Range). A pair of these sub-TLVs is describing a given O-E-O piece of equipment. Hence, there will be an instance of a pair of these sub- TLVs for each O-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. 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: Peloso and Meuric Expires September 1, 2010 [Page 6] Internet-Draft OSPF Extensions for O-E-O in WSON March 2010 Type Name TBD Pool ID TBD Ingress Available Wavelength TBD Egress Available Wavelength 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. Peloso and Meuric Expires September 1, 2010 [Page 7] Internet-Draft OSPF Extensions for O-E-O in WSON March 2010 [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 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 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 Peloso and Meuric Expires September 1, 2010 [Page 8] Internet-Draft OSPF Extensions for O-E-O in WSON March 2010 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 1, 2010 [Page 9]