Network Working Group Fatai Zhang Internet Draft Dan Li Category: Standards Track Huawei Han Li CMCC S.Belotti Alcatel-Lucent Expires: June 2010 December 18, 2009 Framework for GMPLS and PCE Control of G.709 Optical Transport Networks draft-zhang-ccamp-gmpls-g709-framework-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 June 17, 2010. Abstract This document provides a framework to allow the development of protocol extensions to support Generalized Mulit-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTN) as specified in ITU-T Recommendation G.709. zhang Expires June 2010 [Page 1] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 [Note: including the enhanced functionality in the version consented 10/2009.] 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 [RFC2119]. Table of Contents 1. Introduction.................................................2 2. Terminology..................................................3 3. G.709 Optical Transport Network (OTN)........................4 3.1. OTN Layer Network.......................................4 4. Connection management in OTN.................................9 4.1. Connection management of OCh...........................10 4.2. Connection management of the ODU.......................10 5. GMPLS/PCE Implications......................................12 5.1. Implications for LSP Hierarchy with GMPLS TE...........12 5.2. Implications for GMPLS Signaling.......................12 5.2.1. Identifying OTN signals...........................13 5.2.2. Tributary Port Number.............................14 5.3. Implications for GMPLS Routing.........................14 5.3.1. Requirement for conveying Interface Switching Capability specific information...................14 5.4. Implications for Link Management Protocol (LMP)........15 5.4.1. Correlating the Granularity of the TS.............15 5.4.2. Correlating the Supported LO ODU Signal Types.....15 5.5. Implications for Path Computation Elements.............16 6. Security Considerations.....................................16 7. IANA Considerations.........................................16 8. Acknowledgments.............................................16 APPENDIX A: Description of LO ODU terminology and ODU connection examples...........................................17 9. References..................................................19 9.1. Normative References...................................19 9.2. Informative References.................................20 10. Author's Addresses.........................................20 1. Introduction OTN has become a mainstream layer 1 technology for the transport network. It is desirable for operators to be able to introduce control plane capabilities based on Generalized Multi-Protocol Label zhang Expires June 2010 [Page 2] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 Switching (GMPLS) to OTN networks, so as to realize its associated benefits (e.g., improved network resiliency, resource usage efficiency, etc.). GMPLS extends MPLS to encompass time division multiplexing (TDM) networks (e.g., SONET/SDH, PDH, and G.709 sub-lambda), lambda switching optical networks, and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The GMPLS architecture is provided in[RFC3945], signaling function and Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are described in [RFC3471] and [RFC3473], routing and OSPF extensions are described in [RFC4202] and [RFC4203], and the link management protocol is described in [RFC4204]. The existing GMPLS protocol suite provides the mechanisms for basic GMPLS control of OTN networks, using ITU-T G.709 interfaces as specified in 2003 [ITU-T-G.709]. It should be noted that there are some differences between SDH/SONET TDM networks and OTN networks resulting from some new features recently introduced in ITU-T; for example, various multiplexing structures, two types of Tributary Slots (i.e., 1.25Gbps and 2.5Gbps), and extension of the ODUj definition to include the ODUflex function. This document reviews relevant aspects of OTN technology evolution affecting GMPLS control plane protocols, including PCE implications, and provides a framework for the control of OTN networks. For the purposes of the control plane the OTN can be considered as being comprised of sub-wavelength (ODU) and wavelength (OCh) layers. This document focuses on the control of the sub-wavelength layer, with control of the wavelength layer considered out of the scope. Please refer to [WSON-Frame] for further information. [Note: It is intended to align this draft with G.709 (consented in 10/2009), G.872 and G.8080 (planned for consent in 6/2010)] 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 [RFC2119]. zhang Expires June 2010 [Page 3] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 3. G.709 Optical Transport Network (OTN) This section provides an informative overview of those aspects of the OTN impacting control plane protocols. This overview is based on the ITU-T Recommendations that contain the normative definition of the OTN. Technical details regarding OTN architecture and interfaces are provided in the relevant ITU-T Recommendations. Specifically, [ITU-T-G.872] describes the functional architecture of optical transport networks providing optical signal transmission, multiplexing, routing, supervision, performance assessment, and network survivability. [ITU-T-G.709] defines the interfaces of the optical transport network to be used within and between subnetworks of the optical network. With the evolution and deployment of OTN technology many new features have been specified in ITU-T recommendations, including for example, new ODU0, ODU2e, ODU4 and ODUflex containers as described in [G709-V3]. 3.1. OTN Layer Network The simplified structure of OTN is shown in Figure 1, which illustrates the layers that are of interest to the control plane. Other layers below OCh (e.g. OTS) are not included in this Figure. The full signal structure is provided in G.709. Client signal | ODUj | OTU/OCh OMS Figure 1 Basic OTN signal structure Client signals are mapped into the appropriate ODUj containers. These ODUj containers are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are combined in the OMS (using WDM multiplexing), and this aggregated signal provides the link between the nodes. zhang Expires June 2010 [Page 4] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 3.1.1 Client signal mapping The client signals are mapped into a Low Order (LO) ODUj. Appendix A gives more information about LO ODU. The current values of j are: 0, 1, 2, 2e, 3, 4, Flex. The approximate bit rates of these signals are defined in 2 [G709-V3] and are reproduced in Tables 1 and 2. +-----------------------+-----------------------------------+ | ODU Type | ODU nominal bit rate | +-----------------------+-----------------------------------+ | ODU0 | 1 244 160 kbits/s | | ODU1 | 239/238 x 2 488 320 kbit/s | | ODU2 | 239/237 x 9 953 280 kbit/s | | ODU3 | 239/236 x 39 813 120 kbit/s | | ODU4 | 239/227 x 99 532 800 kbit/s | | ODU2e | 239/237 x 10 312 500 kbit/s | | ODUflex for CBR | | | Client signals | 239/238 x client signal bit rate | | ODUflex for GFP-F | | | Mapped client signal | Configured bit rate | +-----------------------+-----------------------------------+ Table 1 ODU types and bit rates NOTE - The nominal ODUk rates are approximately: 2 498 775.126 kbit/s (ODU1), 10 037 273.924 kbit/s (ODU2), 40 319 218.983 kbit/s (ODU3), 104 794 445.815 kbit/s (ODU4) and 10 399 525.316 kbit/s (ODU2e). zhang Expires June 2010 [Page 5] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 +-------------------+--------------------------------------+ | ODU Type | ODU bit-rate tolerance | +-------------------+--------------------------------------+ | ODU0 | +- 20 ppm | | ODU1 | +- 20 ppm | | ODU2 | +- 20 ppm | | ODU3 | +- 20 ppm | | ODU4 | +- 20 ppm | | ODU2e | +- 100 ppm | | ODUflex for CBR | | | Client signals | client signal bit rate tolerance, | | | with a maximum of+-100 ppm | | ODUflex for GFP-F | | | Mapped client | +- 20 ppm | | signal | | +-------------------+--------------------------------------+ Table 2 ODU types and tolerance The ODUflex uses one of two mapping options depending on the client signal type: - Circuit clients: are proportionally wrapped, thus the bit rate and tolerance are defined by the client signal. - Packet clients are GFP mapped: G.709 recommends that the bit rate is set to an integer multiplier of HO OPUk TS rate, the tolerance is +/- 20ppm and the bit rate is determined by the node that performs the mapping. 3.1.1.1 ODUj types and parameters Some information needs to be provided when ODUj connections are setup. We have two types of information that should be conveyed in a connection request: (a)End to end: Client payload type (e.g. STM64; Ethernet etc.) Bit rate and tolerance: Note for j = 0, 1, 2, 2e, 3, 4 this information may be carried as an enumerated type. For the ODUflex the actual bit rate and tolerance must be provided. (b)Link by link: zhang Expires June 2010 [Page 6] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 TS assignment and port number (carried by the MSI bytes) as described in section 3.1.2. 3.1.2 Multiplexing ODUj onto Links The links between the switching nodes are provided by one or more wavelengths. Each wavelength carries one OCh, which carries one OTU, which carries one OPU. Since all of these signals have a 1:1:1 relationship, we only refer to the OTU for clarity. The ODUjs are mapped into the Tributary Slots (TS) of the OTUk. Note that in the case where j=k the ODUj is mapped into the OTU/OCh without multiplexing. The initial versions of G.709 only provided a single TS granularity, nominally 2.5Gb/s. Amendment 3, approved in 2009, added an additional TS granularity, nominally 1.25Gb/s. The number and type of TSs provided by each of the currently identified OTUk is provided below: 2.5Gb/s 1.25Gb/s Nominal Bit rate OTU1 1 2 2.5Gb/s OTU2 4 8 10Gb/s OTU3 16 32 40Gb/s OTU4 -- 80 100Gb/s To maintain backwards compatibility while providing the ability to interconnect nodes that support 1.25Gb/s TS at one end of a link and 2.5Gb/s TS at the other, the ''new'' equipment will fall back to the use of a 2.5Gb/s TS if connected to legacy equipment. This information is carried in band by the payload type. [Note: Automatic negotiation may be added in a future version of G.798, otherwise the discovery extensions described below will be required]. The actual bit rate of the TS in an OTUk depends on the value of k. Thus the number of TS occupied by an ODUj may vary depending on the values of j and k. For example an ODU2e uses 9TS in an OTU3 but only 8 in an OTU4. Examples of the number of TS used for various cases are provided below: zhang Expires June 2010 [Page 7] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 - ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS granularity o ODU0 occupies 1 of the 2, 8, 32or 80 TS for ODU1, ODU2, ODU3 or ODU4 - ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS granularity o ODU1 occupies 2 of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4 - ODU1 into ODU2, ODU3 multiplexing with 2.5Gbps TS granularity o ODU1 occupies 1 of the 4 or 16 TS for ODU2 or ODU3 - ODU2 into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity o ODU2 occupies 8 of the 32 or 80 TS for ODU3 or ODU4 - ODU2 into ODU3 multiplexing with 2.5Gbps TS granularity o ODU2 occupies 4 of the 16 TS for ODU3 - ODU3 into ODU4 multiplexing with 1.25Gbps TS granularity o ODU3 occupies 31 of the 80 TS for ODU4 - ODUflex into ODU2, ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity o ODUflex occupies n of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4 (n <= Total TS numbers of ODUk) - ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity o ODU2e occupies 9 of the 32 TS for ODU3 or 8 of the 80 TS for ODU4 An ODUj must be carried by a single OTU. The available capacity between nodes is the sum of the available capacity on the OTUs that interconnect the nodes. This total capacity is represented as a link bundle. Note that the available capacity will typically be distributed across multiple OTUs, thus the maximum payload size (i.e. the maximum number of TS on the bundled link which is determined by a single OTU with the maximum number of TS) should also be provided. A (local) Tributary Port Number (TPN) for the TS to be used to carry an ODUj must be provided when an ODUj connection is set up. This zhang Expires June 2010 [Page 8] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 information is mapped into the MSI bytes. The control plane must convey the TPN information to the receiving end of the link. The TPN is used (by the hardware) at the receiving end of the link to verify the configuration. In general the mapping of an ODUj (including ODUflex) into the OTUk TSs is determined locally, and it can also be explicitly allocated by a specific entity (e.g., head end, NMS) through Explicit Label Control [RFC3473]. The allocation of the fixed and variable stuff bytes is dependent on the bit rate and bit rate tolerance of the payload being mapped and the TS capacity of the (local) OTUk link that has been selected. 3.1.2.1 Link Parameters The critical parameters that need to be provided (for the purposes of routing) are: - Number of TS - Maximum number of TS available for a LSP (i.e., Maximum LSP Bandwidth) - Bit rate of the TS. (Note: This may be efficiently encoded as a two integers representing the value of k and the granularity.) 4. Connection management in OTN As [ITU-T-G.872] described, OTN-based transport network equipment is concerned with control of connectivity of ODU paths and optical channels and not with control of connectivity of the client layer. This document focuses on the connection management of ODU paths. The management of OCh paths is described in [WSON-FRAME]. [Note: Work is currently in progress in Q.12/15 to update G.872 to describe the ODU layer as a single layer network with the bit rate as a parameter. This allows the links and nodes to be viewed in a single topology as a common set of resources that are available to provide ODUj connects (independent of the value of j). Optionally the OCh layer may also be visible within this routing topology. zhang Expires June 2010 [Page 9] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 4.1. Connection management of OCh An OCh connection request needs a light path from source to destination. This path computation is known as the Routing and Wavelength Assignment (RWA) problem [HZang00]. In the case of full wavelength converters at each node, OCh path computation is equivalent to a circuit-switch TDM network with full time slot interchange capability. The control of connectivity of optical channels is within the scope of WSON (Wavelength Switched Optical Networks) ongoing working in CCAMP Working Group in IETF. OCh connections are managed as part of the ODU connection set up. OCh connections do not exist outside the scope of a ODU in the OTN. 4.2. Connection management of the ODU LO ODUj can be either mapped into the OTUk signal (j = k), or multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is mapped into an OCh. See Appendix A for more information. From the perspective of routing for the case where j < k (i.e. ODUjs are multiplexed onto an OTUk) the topology may be viewed as illustrated below. In the case of LO ODUj mapping into OTUk (k = j), Figure 2 give an example of this kind of LO ODU connection. Link #5 +--+---+--+ Link #4 +--------------------------| |--------------------------+ | | ODXC | | | +---------+ | | Node E | | | +-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++ | |Link #1 | |Link #2 | |Link #3 | | | |--------| |--------| |--------| | | ODXC | | ODXC | | ODXC | | ODXC | +---------+ +---------+ +---------+ +---------+ Node A Node B Node C Node D Figure 2 Example Topology for connection LO ODU connection management If an ODUj connection is requested (for example) between Node C and Node E routing/path computation must select a path that has the required number of TS available and that offers the lowest cost. Signaling is then invoked to set up the path and to provide the information required by each transit node to allow the configuration of the ODUj to OTUk multiplexing and demultiplexing. At each node at the ingress end of the zhang Expires June 2010 [Page 10] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 link the TS to be used are selected and the fixed and variable stuffing bytes are selected using the ODUj parameters described above. If the ODUj is an ODU1, ODU2, ODU3 or ODU4 it may be mapped directly on to a corresponding OTUk (j = k). An operator may choose to allow this option to be visible to the ODU routing/path computation process in which case the topology would be as shown below in figure 4 Node E Link #5 +---------+ Link #4 +--------------------------| |-------------------------+ | ------ | | // \\ | | || || | | | RWA domain | | +-+-------+ +----+- || || ------+ +-------+-+ | | | \\ // | | | | |Link #1 | -------- |Link #3 | | | +--------+ | | +--------+ + | ODXC | | ODXC +--------+ ODXC | | ODXC | +---------+ +---------+Link #2 +---------+ +---------+ Node A Node B Node C Node D Figure 3 RWA Hidden Topology for connection LO ODU connection management In Figure 3 , a cloud representing OCH capable switching nodes is represented. In this case the operator choice is to hide the real RWA network topology. Link #5 +---------+ Link #4 +--------------------------| |-------------------------+ | +----+ ODXC |----+ | | +-++ +---------+ ++-+ | | Node f + + Node E + + Node g | | +-++ ++-+ | | | +--+ | | +-+-------+ +----+----+--| +--+-----+---+ +-------+-+ | |Link #1 | | +--+ | |Link #3 | | | +--------+ | Node h | +--------+ + | ODXC | | ODXC +--------+ ODXC | | ODXC | +---------+ +---------+ Link #2+---------+ +---------+ Node A Node B Node C Node D Figure 4 RWA Visible Topology for LO ODUj (with direct mapping on OTUk K=j) connection management. zhang Expires June 2010 [Page 11] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 In Figure 4, the cloud of previous figure is substitute by the real topology. The nodes f,g,h are nodes with OCH switching capability. LO ODU j mapping over OTU k=J is represented by the alternative links between nodes C, node g, node E, node f, node B and node h. In this case the ODU routing/path selection process will request an OCh connection between node C to node E from the RWA domain. The connection will appear at ODU level as a Forwarding adjacency. The ODU routing/path selection will compare the cost of this connection (FA) to the cost of using the (visible) links used in case of j j)container. Consequently, the HO ODUk represents the entity transporting a multiplex of LO ODUj tributary signals in its OPUk area. In the case of LO ODUj mapped into an OTUk (k = j) directly, Figure 5 give an example of this kind of LO ODU connection. In Figure 5, The LO ODUj is switched at the intermediate ODXC node. OCh and OTUk are associated with each other. From the viewpoint of connection management, the management of OTUk is similar with OCh. LO ODUj and OCh/OTUk have client/server relationships. For example, one LO ODU1 connection can be setup between Node A and Node C. This LO ODU1 connection is to be supported by OCh/OTU1 connections, which are to be set up between Node A and Node B and between Node B and Node C. LO ODU1 can be mapped into OTU1 at Node A, demapped from it in Node B, switched at Node B, and then mapped into the next OTU1 and demapped from this OTU1 at Node C. zhang Expires June 2010 [Page 17] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 | LO ODUj | +------------------------------(b)---------------------------+ | | OCh/OTUk | | OCh/OTUk | | | +--------(a)---------+ +--------(a)---------+ | | | | | | | +------++-+ +--+---+--+ +-++------+ | |EO| |OE| |EO| |OE| | | +--+----------------+--+ +--+----------------+--+ | | ODXC | | ODXC | | ODXC | +---------+ +---------+ +---------+ Node A Node B Node C Figure 5 Connection of LO ODUj (1) In the case of LO ODUj multiplexing into HO ODUk, Figure 6 gives an example of this kind of LO ODU connection. In Figure 6, OCh, OTUk, HO ODUk are associated with each other. The LO ODUj is multiplexed/de-multiplexed into/from the HO ODU at each ODXC node and switched at each ODXC node (i.e. trib port to line port, line card to line port, line port to trib port). From the viewpoint of connection management, the management of these HO ODUk and OTUk are similar to OCh. LO ODUj and OCh/OTUk/HO ODUk have client/server relationships. when a LO ODU connection is setup, it will be using the existing HO ODUk (/OTUk/OCh) connections which have been set up. Those HO ODUk connections provide LO ODU links, of which the LO ODU connection manager requests a link connection to support the LO ODU connection. For example, one HO ODU2 (/OTU2/OCh) connection can be setup between Node A and Node B, another HO ODU3 (/OTU3/OCh) connection can be setup between Node B and Node C. LO ODU1 can be generated at Node A, switched to one of the 10G line ports and multiplexed into a HO ODU2 at Node A, demultiplexed from the HO ODU2 at Node B, switched at Node B to one of the 40G line ports and multiplexed into HO ODU3 at Node B, demultiplexed from HO ODU3 at Node C and switched to its LO ODU1 terminating port at Node C. zhang Expires June 2010 [Page 18] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 | LO ODUj | +----------------------------(b)-----------------------------+ | | OCh/OTUk/HO ODUk | | OCh/OTUk/HO ODUk | | | +--------(c)---------+ +---------(c)--------+ | | | | | | | +------++-+ +--+---+--+ +-++------+ | |EO| |OE| |EO| |OE| | | +--+----------------+--+ +--+----------------+--+ | | ODXC | | ODXC | | ODXC | +---------+ +---------+ +---------+ Node A Node B Node C Figure 6 Connection of LO ODUj (2) 9. References 9.1. Normative References [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, Jan 2006. [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4202] K. Kompella, Y. Rekhter, Ed., " Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4206] K. Kompella, Y. Rekhter, Ed., " Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. zhang Expires June 2010 [Page 19] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 9.2. Informative References [ITU-T-G.709] ITU-T, "Interface for the Optical Transport Network (OTN)," G.709 Recommendation, March 2003. [ITU-T-G.872] ITU-T, "Architecture of optical transport networks", November 2001 (11 2001). [Gsup43] ITU-T, "Transport of IEEE 10GBASE-R in optical transport networks (OTN)", December 2008. [G709-V3] ITU-T, "Draft revised G.709, version 3,", consented by ITU-T Oct 2009. [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing and wavelength assignment approaches for wavelength- routed optical WDM networks", Optical Networks Magazine, January 2000. [WSON-FRAME] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)", draft-ietf-ccamp-rwa-wson-framework, work in progress. [PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai Zhang, "Requirements for GMPLS applications of PCE", draft-ietf-pce-gmpls-aps-req-01.txt, July 2009. 10. Authors' Addresses Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972912 Email: zhangfatai@huawei.com Dan Li Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China zhang Expires June 2010 [Page 20] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 Phone: +86-755-28973237 Email: danli@huawei.com Han Li China Mobile Communications Corporation 53 A Xibianmennei Ave. Xuanwu District Beijing 100053 P.R. China Phone: +86-10-66006688 Email: lihan@chinamobile.com Sergio Belotti Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate (Milano) Italy +39 039 6863033 Email: sergio.belotti@alcatel-lucent.it 11. Contributors Jianrui Han Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972913 Email: hanjianrui@huawei.com Malcolm Betts Huawei Technologies Co., Ltd. Email: malcolm.betts@huawei.com Pietro Grandi Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate (Milano) Italy +39 039 6864930 zhang Expires June 2010 [Page 21] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 Email: pietro_vittorio.grandi@alcatel-lucent.it Eve Varma Alcatel-Lucent 1A-261, 600-700 Mountain Av PO Box 636 Murray Hill, NJ 07974-0636 USA Email: eve.varma@alcatel-lucent.com Intellectual Property 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. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. zhang Expires June 2010 [Page 22] draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009 For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. 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. Full Copyright Statement 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. zhang Expires June 2010 [Page 23]