CCAMP Working Group Richard Rabbat (Fujitsu) Internet Draft Vishal Sharma (Metanoia, Inc.) Expires: January 2005 Takeo Hamada (Fujitsu) July 2004 Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies draft-rabbat-ccamp-carrier-survey-00.txt Status of this Memo "By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668." 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. Abstract Optical transport networks controlled by a GMPLS-based control plane enable todayÆs network operators to offer valuable new services. With the completion of a number of GMPLS signaling and routing standards and the availability of products implementing them, providers are now looking at ways to enable additional features such as shared-mesh restoration. This document presents the results of a serious attempt to systematically gather and collate carrier inputs on strategies for shared-mesh restoration and the associated issues. The survey results are presented in aggregate form to provide an overview of carrier thinking, while retaining specific carrier response confidentiality. The goal is to highlight areas of carrier concerns, and identify specific work items to focus on and facilitate further discussion. Expires - January 2005 [Page 1] draft-rabbat-ccamp-carrier-survey-00.txt July 2004 Table of Contents 1. Introduction.....................................................2 2. Terminology......................................................3 3. Survey Overview and Methodology..................................3 4. Acknowledgements.................................................3 5. Survey Results...................................................4 5.1 Key Concerns with a GMPLS-based Control Plane...................4 5.2 Plans for Implementing Shared-Mesh Restoration..................4 5.3 Attributes Key to the Adoption of Shared-Mesh Restoration.......5 5.4 Recovery Speed Required.........................................5 5.5 Value of Recovery Speed for Key Applications....................6 5.6 View on Current Signaling-based Solutions.......................7 6. Conclusions......................................................7 7. References.......................................................7 7.1 Normative References............................................7 7.2 Informative References..........................................8 8. Authors' Addresses...............................................9 9. Intellectual Property............................................9 10. Full Copyright Statement........................................9 Appendix A. Sample Survey Format...................................10 1. Introduction The CCAMP WG has recently completed (or nearly completed) a series of GMPLS standards, ranging from signaling and routing protocol specifications for the IP-control of non-packet networks (specifically, optical transport networks)(e.g. [3],[4],[5],[6],[7]) to the development of protection and restoration terminology, analysis, and functional documents (e.g. [8],[9],[10]). These documents have provided a good foundation for further work in the area, especially given that carriers are beginning now to think seriously about how they will use the GMPLS control plane to enable new and/or advanced services within their networks. This will provide efficiencies for carriers, while providing customers with the same level of service as provided today by less efficient (or more expensive) means. One key area that carriers have looked at is shared mesh restoration and its associated issues. This subject while providing opportunities for resource efficiency also requires carriers to be vigilant about how they will meet various performance guarantees. In that context, several areas of work still need to be addressed within the CCAMP WG to develop interoperable, standards-based solutions that carriers can embrace. Expires - January 2005 [Page 2] draft-rabbat-ccamp-carrier-survey-00.txt July 2004 This document presents the collated results from a survey of several major international carriers from the US, Europe and Japan, conducted over the last 5 months. The goal of the survey was to systematically collect carrier inputs in key areas related to control plane operation and shared mesh restoration, and highlight areas for further work by the CCAMP WG. This is to enable the CCAMP WG to pursue ongoing and further work in this area that is focused towards addressing the identified carrier requirements. The rest of the document details various aspects of this survey. The remainder of the document is organized as follows. In Section 3, we provide a brief overview of the survey and its methodology, while in Section 5 we present the aggregated results of the survey. We conclude in Section 6. 2. Terminology 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 [2]. 3. Survey Overview and Methodology The survey consisted of nine questions directed at various aspects of shared mesh restoration in carrier transport networks, and a sample is shown in Section Appendix A. It was circulated to operations and network planning groups at several major international carriers, and the received responses collated into six major tables that are presented in Section 5. The collation was done simply to preserve carrier anonymity. 4. Acknowledgements We would like to thank the carriers that responded to this survey, some who wished to remain anonymous. In particular, we would like to acknowledge the participation in alphabetical order of British Telecom, Global Crossing, Japan Telecom, and NTT Communications. We would also like to ask carriers whom we did not have the opportunity to contact, to participate in this survey so that their inputs can be included in subsequent versions of this document. Expires - January 2005 [Page 3] draft-rabbat-ccamp-carrier-survey-00.txt July 2004 5. Survey Results In this section, we present the aggregated results from the carrier survey, under six headings. Please note that throughout, 5 represents the most critical concern/attribute, while 1 represents the least important concern/attribute. 5.1 Key Concerns with a GMPLS-based Control Plane The first question sought to get an understanding of some of the areas in which carriers have concerns when thinking of deploying a GMPLS-based control plane. These included the reliability of the control plane (its software and implementation), the speed with which one could communicate over the control plane, the capability of the control plane to integrate with existing NMSs, and the carrier view of the maturity of the vendor offering. Table I. Carrier concerns about an IP-based control plane, such as GMPLS. Number Responding 1 2 3 4 5 a. Reliability [ ] [ 1] [ 2] [ 1] [ 3] b. Speed of communication [ ] [ 2] [ 3] [ 2] [ ] c. Integration with NMS [ 1] [ ] [ 2] [ ] [ 4] d. Maturity of vendor offering [ ] [ ] [ ] [ 4] [ 3] 5.2 Plans for Implementing Shared-Mesh Restoration The goal here was to evaluate the timeframes in which carriers were looking to implement shared mesh restoration using a GMPLS-based control plane. This would impact the time available to develop advanced features of the control plane within CCAMP, and also provide insight into why (or why not) the carriers would adopt a GMPLS-based control plane (as seen later). It is evident from Table II, that there are plans to implement shared mesh restoration in carrier networks in the next 2-3 years. Table II. Plans for implementing shared-mesh restoration in the optical transport network Expires - January 2005 [Page 4] draft-rabbat-ccamp-carrier-survey-00.txt July 2004 Number Responding a. Already implemented [ 1] b. Within 1 year [ ] c. Within 2-3 years [ 3] d. In 3+ years [ ] e. Have no current plans to implement it [ 3] 5.3 Attributes Key to the Adoption of Shared-Mesh Restoration This question was designed simply to assess which attributes of shared mesh restoration were key to a carrier adopting/implementing it. Table III. Importance of key attributes in adopting shared-mesh restoration Number Responding 1 2 3 4 5 a. Speed of recovery [ ] [ ] [ 2] [ ] [ 5] b. Bandwidth savings [ 1] [ ] [ 3] [ 2] [ 1] from using sharing c. Ability to deal with [ ] [ ] [ 3] [ 2] [ 2] multiple fiber cuts 5.4 Recovery Speed Required This question was designed to assess the ranges of recovery speeds carriers deemed appropriate. Table IV. Speed of recovery required Number Responding a. Does not matter [ ] b. 50 milliseconds [ 4] c. 200 milliseconds [ ] Expires - January 2005 [Page 5] draft-rabbat-ccamp-carrier-survey-00.txt July 2004 d. 200 ms - 1 second [ ] e. 1 second-1 minute [ ] f. Other [ 2]. Please specify: 50 to 200ms For some applications, 50ms is required. For others a business case can be made for longer duration restorals. Closer the duct the faster in general, closer the applications the slower in general. 5.5 Value of Recovery Speed for Key Applications In shared mesh restoration and other restoration scenarios, the speed of recovery is often an important parameter. The question below was designed to assess how important carriers thought recovery speed was for the different types of traffic carried on their networks. As might be expected, TDM voice, VoIP, VoD, and business traffic were the primary applications judged to require quick recovery speeds. Table V. Importance of recovery speed for key applications Number Responding 1 2 3 4 5 a. TDM Voice [ ] [ ] [ ] [ 1] [ 5] b. VPN Traffic [ ] [ ] [ ] [ 5] [ 1] c. Web, peer-to-peer [ ] [ 1] [ 1] [ 3] [ 1] d. VoIP [ ] [ ] [ ] [ 3] [ 3] e. Video conferencing, [ ] [ ] [ ] [ 3] [ 3] video-on-demand f. Business traffic such as [ ] [ ] [ 1] [ 2] [ 3] SAP, network storage g. Other best-effort traffic [ ] [ 2] [ 2] [ 1] [ ] No response [ 1] Expires - January 2005 [Page 6] draft-rabbat-ccamp-carrier-survey-00.txt July 2004 5.6 View on Current Signaling-based Solutions A number of mechanisms may be used to perform notification of faults and subsequent recovery actions. The key is to provide scalable ways of disseminating failure information in the network. The question below was designed to assess carrier thinking in this area. As can be seen from Table VI, carriers surveyed uniformly agree that hard bounds on recovery time are very important, and that some aspects of signaling such as scalability and potential signaling storms are areas of concern. Table VI. Level of concern in some key areas for a shared mesh restoration scheme using signaling for notification of each failed LSP Number Responding 1 2 3 4 5 a. Speed of notification [ ] [ 1] [ 1] [ 3] [ 2] b. Network stability [ ] [ ] [ ] [ 2] [ 5] c. Signaling storms such as [ ] [ ] [ ] [ 2] [ 5] when a large # of lambdas fail at the same time due to a single fiber cut d. Scalability of signaling [ ] [ ] [ ] [ 3] [ 4] e. Hard bounds on recovery time [ ] [ ] [ 1] [ 4] [ 2] 6. Conclusions This draft represents survey results from several major carriers in Europe, North America and Japan. The authors collected information related to shared mesh restoration, its advantages and the requirements carriers have for its adoption. 7. References 7.1 Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, IETF RFC 2026, October 1996. Expires - January 2005 [Page 7] draft-rabbat-ccamp-carrier-survey-00.txt July 2004 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, IETF RFC 2119, March 1997. [3] L. Berger (Ed.), "Generalized Multi-protocol Label Switching: Signaling Functional Description," RFC 3471, January 2003. [4] P. Ashwood-Smith, L. Berger (Eds.), "Generalized Multi-protocol Label Switching (GMPLS) Signaling Constraint-based Routed Distribution Label Distribution Protocol Extensions," RFC 3472, January 2003. [5] L. Berger (Ed.) "Generalized Multi-protocol Label Switching (GMPLS) Signaling Resource Reservation Protocol Traffic Engineering Extensions," RFC 3473, January 2003. [6] K. Kompella, Y. Rekhter (Eds.), "Routing Extensions in Support of Generalized Multi-protocol Label Switching," Internet Draft, Work in Progress, draft-ietf-ccamp-gmpls-routing-09.txt, October 2003. [7] K. Kompella, Y. Rekhter (Eds.), "OSPF Extensions in Support of Generalized Multi-protocol Label Switching," Internet Draft, Work in Progress, draft-ietf-ccamp-gmpls-ospf-gmpls-extensions- 12.txt, October 2003. 7.2 Informative References [8] E. Mannie, D. Papadimitriou (Eds.), "Recovery (Protection and Restoration) Terminology for Generalized Multi-protocol Label Switching," Internet Draft, Work in Progress, draft-ietf-ccamp- gmpls-recovery-terminology-04.txt, April 2004. [9] E. Mannie, D. Papadimitriou (Eds.), "Analysis of Generalized Multi-protocol Label Switching based Recovery (Protection and Restoration) Schemes," Internet Draft, Work in Progress, draft- ietf-ccamp-gmpls-recovery-analysis-03.txt, April 2004. [10] J. P. Lang, B. Rajagopalan (Eds.), "Generalized Multi-protocol Label Switching Recovery Functional Specification," Internet Draft, Work in Progress, draft-ietf-ccamp-gmpls-recovery- functional-02.txt, April 2004. Expires - January 2005 [Page 8] draft-rabbat-ccamp-carrier-survey-00.txt July 2004 8. Authors' Addresses Richard Rabbat Vishal Sharma Fujitsu Labs of America, Inc. Metanoia, Inc. 1240 East Arques Ave, MS 345 888 Villa St, Suite 200B Sunnyvale, CA 94085 Mountain View, CA 94041 United States of America United States of America Phone: +1-408-530-4537 Phone: +1-408-530-8313 Email: rabbat@alum.mit.edu Email: v.sharma@ieee.org Takeo Hamada Fujitsu Labs of America, Inc. 1240 East Arques Ave, MS 345 Sunnyvale, CA 94085 United States of America Phone: +1-408-530-4575 Email: thamada@fla.fujitsu.com 9. Intellectual Property The IETF 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 this 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. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR 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 this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 10. Full Copyright Statement "Copyright (C) The Internet Society (2004). This document is subject Expires - January 2005 [Page 9] draft-rabbat-ccamp-carrier-survey-00.txt July 2004 to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Appendix A. Sample Survey Format Carrier Survey about Optical Transport Network ---------------------------------------------- 1. Please provide us with your job title _---------------------------------------- ______________ 2. What is your plan for implementing a GMPLS-based control plane? a. Already deployed it [ ] b. Within 1 year [ ] c. Within 2-3 years [ ] d. In 3+ years [ ] e. Have no current plans to implement it [ ] 3. What is the status of implementation of a GMPLS control plane in your network today? a. Have it in the lab. (trials/testing) [ ] b. Testing it in a research network [ ] c. Have tested it, and proceeding to implementation [ ] d. Have it in parts of our production network [ ] Expires - January 2005 [Page 10] draft-rabbat-ccamp-carrier-survey-00.txt July 2004 e. Full fledged implementation in the network [ ] 4. Please rank your concerns about an IP-based control plane such as GMPLS. (5 is most important concern, 1 is least important concern) 1 2 3 4 5 a. Reliability [ ] [ ] [ ] [ ] [ ] b. Speed of communication [ ] [ ] [ ] [ ] [ ] c. Integration with NMS [ ] [ ] [ ] [ ] [ ] d. Maturity of vendor offering [ ] [ ] [ ] [ ] [ ] Note: For the purposes of this survey, we define transport networks that implement shared-mesh restoration as follows. In such networks, the working paths are protected by shared protection resources. As an example, a protection path can protect two working paths and be used to restore traffic when either of the working wavelengths fails. In other cases of shared-mesh restoration, a carrier allows extra- traffic between endpoints other than the source-destination of a protection path. Thus a protection path cannot be cross-connected until after the specific failure has occurred. 5. What are you plans for implementing shared-mesh restoration in your optical transport network? a. Already implemented [ ] b. Within 1 year [ ] c. Within 2-3 years [ ] d. In 3+ years [ ] e. Have no current plans to implement it [ ] 6. To adopt shared mesh protection, please rank the importance (from 1 to 5) of each of the following attributes. (1 is least important, 5 is most important) 1 2 3 4 5 Expires - January 2005 [Page 11] draft-rabbat-ccamp-carrier-survey-00.txt July 2004 a. Speed of recovery [ ] [ ] [ ] [ ] [ ] b. Bandwidth savings [ ] [ ] [ ] [ ] [ ] from using sharing c. Ability to deal with [ ] [ ] [ ] [ ] [ ] multiple fiber cuts 7. What speed of recovery do you need? a. Does not matter [ ] b. 50 milliseconds [ ] c. 200 milliseconds [ ] d. 200 ms- 1 second [ ] e. 1 second-1 minute [ ] f. Other [ ]. Please specify: ____________ 8. For each of the following services, how important do you believe recovery speed to be? (1:recovery speed is not important, 5:recovery speed is critical) 1 2 3 4 5 a. TDM Voice [ ] [ ] [ ] [ ] [ ] b. VPN Traffic [ ] [ ] [ ] [ ] [ ] c. Web, peer-to-peer [ ] [ ] [ ] [ ] [ ] d. VoIP [ ] [ ] [ ] [ ] [ ] e. Video conferencing, [ ] [ ] [ ] [ ] [ ] video-on-demand f. Business traffic such as [ ] [ ] [ ] [ ] [ ] SAP, network storage g. Other best-effort traffic [ ] [ ] [ ] [ ] [ ] Please specify: ___________ ___________________________ Expires - January 2005 [Page 12] draft-rabbat-ccamp-carrier-survey-00.txt July 2004 9. For a shared mesh restoration scheme that used signaling for notification of each failed LSP, how concerned are you in each of the following areas? (1: I have no concern, 5: I have critical concerns) 1 2 3 4 5 a. Speed of notification [ ] [ ] [ ] [ ] [ ] b. Network stability [ ] [ ] [ ] [ ] [ ] c. Signaling storms such as [ ] [ ] [ ] [ ] [ ] when a large # of lambdas fail at the same time due to a single fiber cut d. Scalability of signaling [ ] [ ] [ ] [ ] [ ] e. Hard bounds on recovery time [ ] [ ] [ ] [ ] [ ] Expires - January 2005 [Page 13]