Network Working Group E. Roch Internet Draft Nortel Networks Intended status: Informational J. Sadler Expires: April 2010 Tellabs October 19, 2009 Signaling for Inverse Multiplexing Schemes via GMPLS using RSVP-TE draft-roch-ccamp-gmpls-inv-mux-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 April 19, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Roch and Sadler Expires April 19, 2010 [Page 1] Internet-Draft draft-roch-ccamp-gmpls-inv-mux October 2009 Abstract A set of requirements and a proposed implementation for the control of the SONET/SDH inverse multiplexing capabilities known as VCAT/LCAS is given in [CCAMP-VCAT]. However, implementations based on OIF implementation agreements and their prototype extensions have identified gaps in [CCAMP-VCAT]. This draft proposes a wider scoped alternative implementation approach that addresses the requirements of [CCAMP-VCAT] and additional requirements of independent setup of the VCAT group and its members. Table of Contents 1. Introduction...................................................2 2. Conventions....................................................2 3. Use Cases and Requirements.....................................3 4. Signaling Extensions...........................................3 4.1. Extension for IMG layer identification....................4 4.2. Extension for IMG bandwidth...............................4 5. Security Considerations........................................5 6. IANA Considerations............................................5 7. References.....................................................5 7.1. Normative References......................................5 8. Acknowledgments................................................6 1. Introduction The Optical Internetworking Forum (www.oiforum.com) has demonstrated signaling for inverse multiplexing in several of its worldwide interoperability events in 2005, 2007 and 2009. The OIF demos included signaling for Ethernet over VCAT control plane enabled connections. The demos included separate call and connection signaling for Ethernet, VCAT and STS-1/VC-4. This is the model described in [LIAISON-291]. In order to perform the various interoperability events, some experimental extensions were tested and included the use of the NVC field of SONET/SDH SENDER_TSPEC in the VCAT layer signaling to indicate that the RSVP signaling exchanged pertained to VCAT. This approach, however, is not compatible with GMPLS implementations and could only be used in this experimental setting. 2. Conventions The following abbreviation is used in this document: Roch and Sadler Expires April 19, 2010 [Page 2] Internet-Draft draft-roch-ccamp-gmpls-inv-mux October 2009 IMG: Inverse Multiplexing Group 3. Use Cases and Requirements In a scenario where several signals are inverse multiplexed together to form an Inverse Multiplexing Group (IMG), it is possible that the IMG is established by the control plane but that the IMG members are not. Even in the case that the IMG members are control plane established, the members might be separately administered and policies may prevent signaling control information related to the IMG to be exchanged in the IMG member signaling. This results in a requirement to support independent signaling for the IMG and its members. This is a gap in [CCAMP-VCAT] because it piggybacks the VCAT call signaling CALL_ATTRIBUTES onto VCAT member signaling. If the IMG members are provisioned or if it is control plane enabled but does not allow piggybacking of IMG information onto its own signaling, it is not possible to use the procedure described in [CCAMP-VCAT]. Business and/or regulatory requirements have caused the separation of "advanced telecommunications service" entities from traditional transport entities. The result of this has placed the management of data equipment, e.g. Ethernet switches, into a separate group from transport equipment. Given that the inverse multiplexing of a number of TDM connections together to satisfy requirements of the "advanced telecommunications service" organization is opaque to the transport organization, the configuration of the VCAT group cannot be piggybacked on the signaling for the TDM connections. 4. Signaling Extensions This section proposes a solution where signaling for an IMG and its members are performed independently, each requiring its own RSVP session and associated messaging. The IMG member signaling follows existing RSVP-TE based GMPLS signaling for the corresponding member signal. The IMG signaling is based on existing RSVP-TE based GMPLS signaling described in [RFC3471] and [RFC3473] with the following modifications: - A mechanism to identify that RSVP-TE signaling is reserving member resources for an IMG, described in this document. - A more generic mechanism to specify the requested bandwidth, described in this document. Roch and Sadler Expires April 19, 2010 [Page 3] Internet-Draft draft-roch-ccamp-gmpls-inv-mux October 2009 - A mechanism that allows an RSVP_HOP to include several sub-TLVs for each direction, where each sub-TLV uniquely identifies one of the members of the IMG. A suitable solution could reuse the encoding from [MT_BDL]. 4.1. Extension for IMG signaling identification In order to identify that the signaling is related to an inverse multiplexing group, there has to be an indication in the signaling message. For example, a new Switching Type value could be defined for the RSVP-TE Generalized Label Request [RFC3473][RFC3471]. A new switching type (TBD) for Inverse Multiplexing Capable is defined. Value Type ----- ---- TBD Inverse-Multiplex Capable (IMC) 4.2. Extension for IMG bandwidth In order to identify the bandwidth for an IMG, a description of the members and their numbers is necessary. A new IMG SENDER_TSPEC (Class 12, C-TYPE TBD)/FLOWSPEC (Class 9, C-TYPE TBD) is defined 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (Variable) | Class (12/9) | C-Type (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type | Number of Members | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signal Type can take the following values, based on [CCAMP-VCAT]: Value Type (Elementary Signal) ----- ------------------------ 1 VT1.5 SPE / VC-11 2 VT2 SPE / VC-12 3 STS-1 SPE / VC-3 4 STS-3c SPE / VC-4 11 OPU1 (i.e., 2.5 Gbit/s 12 OPU2 (i.e., 10 Gbit/s) 13 OPU3 (i.e., 40 Gbit/s) Roch and Sadler Expires April 19, 2010 [Page 4] Internet-Draft draft-roch-ccamp-gmpls-inv-mux October 2009 21 T1 (i.e., 1.544 Mbps) 22 E1 (i.e., 2.048 Mbps) 23 E3 (i.e., 34.368 Mbps) 24 T3 (i.e., 44.736 Mbps) 5. Security Considerations This document does not identify any security issues. 6. IANA Considerations New Switching type for Inverse-Multiplex Capable (ICM). New C-Type for SENDER_TSPEC/FLOWSPEC for IMG. 7. References 7.1. Normative References [CCAMP-VCAT] Bernstein, G. (Editor), "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustement Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)", draft- ietf-ccamp-gmpls-vcat-lcas-08.txt, July 2009. [G.805] ITU-T Rec G.805, "Generic functional architecture of transport networks", March 2000. [G.8080] ITU-T Rec G.8080/Y.1304, "Architecture for the Automatically Switched Optical Network (ASON)", June 2006. [LIAISON-291] ITU-T SG15, "Response to IETF CCAMP WG LS (TD314/3) on Notification of work in the IETF CCAMP working group", November 2006. [MT_BDL] Sadler, J. "Multiplier (MT) support over Bundled Links in RSVP-TE", draft-sadler-ccamp-rsvp-mt-bundled-links-00.txt, October 2009. [RFC3471] Berger, L. "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC3471, January 2003. [RFC3473] Berger, L. "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC3473, January 2003. Roch and Sadler Expires April 19, 2010 [Page 5] Internet-Draft draft-roch-ccamp-gmpls-inv-mux October 2009 8. Acknowledgments The authors would like to thank the following OIF members for their comments and support for this document: Xihua Fu (ZTE Corporation) Remi Theillaud (Marben Products) This document was prepared using 2-Word-v2.0.template.dot. Roch and Sadler Expires April 19, 2010 [Page 6] Internet-Draft draft-roch-ccamp-gmpls-inv-mux October 2009 Authors' Addresses Evelyne Roch Nortel Networks 3500 Carling Avenue Ottawa, ON K2H 8E9 Canada Email: eroch@nortel.com Jonathan Sadler Tellabs 1415 W. Diehl Rd. Naperville, IL 60565 USA Email: jonathan.sadler@tellabs.com Roch and Sadler Expires April 19, 2010 [Page 7]