Network Working Group
TomohiroT. Otani Internet-Draft KDDI Intended status: Informational KenichiK. Ogaki Expires: September 13, 2013 KDDI R&D Labs DiegoLabs. D. Caviglia Ericsson FataiF. Zhang Huawei Expires: December 27, 2012 June 27, 2012Technologies Co., Ltd. C. Cyril Nokia Siemens Networks Optical GmbH March 12, 2013 Requirements for GMPLS applications of PCE Document: draft-ietf-pce-gmpls-aps-req-06.txtdraft-ietf-pce-gmpls-aps-req-07.txt Abstract The initial effort of the PCE WG is specifically focused on MPLS (Multi-protocol label switching). As a next step, this draft describes functional requirements for GMPLS (Generalized MPLS) application of PCE (Path computation element). Status of this Memo This Internet-Draft is submitted to IETFin 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.(IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts.Drafts is at http://datatracker.ietf.org/drafts/current/. 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 December 27, 2012. Abstract The initial effort of PCE WGSeptember 13, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is specifically focusedsubject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on MPLS (Multi- protocol label switching). As a next step, this draft describes functional requirements for GMPLS (Generalized MPLS) applicationthe date of publication of PCE (Path computation element). Conventions used inthis document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",document. Please review these documents carefully, as they describe your rights and "OPTIONAL" inrestrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are to be interpretedprovided without warranty as described in RFC-2119 [RFC2119].the Simplified BSD License. Table of Contents 1. Introduction ................................................. 2 2. Terminology ................................................... . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. GMPLS applications of PCE .................................... 3 3.1. GMPLS network model ...................................... . . . . . . . . . . . . . . . . . 3 188.8.131.52. Path computation in GMPLS network ....................... 4 3.3.. . . . . . . . . . . . 3 2.2. Unnumbered Interfaces ...................................Interface . . . . . . . . . . . . . . . . . . . 6 184.108.40.206. Asymmetric Bandwidth Path Computation .................... . . . . . . . . . 6 4.3. Requirements for GMPLS application of PCE ..................... . . . . . . . . . 6 220.127.116.11. Requirements ofon Path Computation Request ................. . . . . . . . . 6 18.104.22.168. Requirements ofon Path Computation Reply .................. 8 4.3.. . . . . . . . . . 7 3.3. GMPLS PCE Management .................................... 9 5.. . . . . . . . . . . . . . . . . . . 8 4. Security consideration ....................................... 9 6.Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations ........................................... . . . . . . . . . . . . . . . . . . . . 9 7.6. Acknowledgement ............................................... . . . . . . . . . . . . . . . . . . . . . . 9 8.7. References .................................................... . . . . . . . . . . . . . . . . . . . . . . . . . 9 22.214.171.124. Normative References.....................................References . . . . . . . . . . . . . . . . . . . 9 126.96.36.199. Informative References................................... 11 9.References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses ........................................... 13. . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The initial effort of the PCE WG is focused on solving the path computation problem within a domain or over different domains in MPLS networks. As the same case with MPLS, service providers (SPs) have also come up with requirements for path computation in GMPLSGMPLS- controlled networks such as wavelength, TDM-based or Ethernet-based networks as well. [RFC4655] and [RFC4657] discuss the framework and requirements for PCE on both packet MPLS networks and (non-packet switch capable) GMPLSGMPLS-controlled networks. This document complements these documentsRFCs by providing some considerations of GMPLS applications in the intra- domainintra-domain and inter-domain networking environments and indicating a set of requirements for the extended definition of series of PCE relatedPCE-related protocols. Note that the requirements for inter-layer traffic engineering described in [RFC6457] are outside of the scope of this document. Constraint basedConstraint-based shortest path first (CSPF) computation within a domain or over domains for signaling GMPLS Label Switched Paths (LSPs) is usually more stringent than that of MPLS TE LSPs [RFC4216], because the additional constraints, e.g., interface switching capability, link encoding, link protection capability and so forth need to be considered to establish GMPLS LSPs [CSPF].LSPs. GMPLS signaling protocol [RFC3471, RFC3473][RFC3473] is designed taking into account bi-directionality, switching type, encoding type, SRLG,SRLGs and protection attributes of the TE links spanned by the path, as well as LSP encoding and switching type forof the end points, appropriately. This document provides the investigated results of GMPLS applications of PCE for the support of GMPLS path computation. This document also provides requirements for GMPLS applications of PCE in GMPLS intra-domainintra- domain and inter-domain environments. 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]. 3.GMPLS applications of PCE 3.1. GMPLS network model Figure 1 depicts a typical network, consisting of several GMPLS domains, assumed in this document. D1, D2, D3 and D4 have multiple inter-domain links, while D5 has only one inter-domain link. These domains follow the definition in [RFC4726]. +---------+ +---------|GMPLS D2|----------+ | +----+----+ | +----+----+ | +----+----+ +---------+ |GMPLS D1| | |GMPLS D4|---|GMPLS D5| +----+----+ | +----+----+ +---------+ | +----+----+ | +---------|GMPLS D3|----------+ +---------+ Figure 1: GMPLS Inter-domain network model. Each domain is configured using various switching and link technologies defined in [RFC3945] and an end-to-end route needs to respect TE link attributes like switching capability, encoding type, etc., making the problem a bit different from the case of classical (packet) MPLS. In order to route from one GMPLS domain to another GMPLS domain appropriately, each domain manages traffic engineering database (TED) by PCE, and exchanges or provides route information of paths, while concealing its internal topology information. 188.8.131.52. Path computation in GMPLS network [CSPF] describes consideration of GMPLS TE attributes during path computation.Figure 21 depicts a typical GMPLS network, consisting of an ingress link, a transit link as well as an egress link, to investigate a consistent guideline for GMPLS path computation. Each link at each interface has its own switching capability, encoding type and bandwidth. Ingress Transit Egress +-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+ |Node1|------------>|Node2|------------>|Node3|------------>|Node4| | |<------------| |<------------| |<------------| | +-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+ Figure 2:1: Path computation in GMPLS networks.networks For the simplicity in consideration, the below basic assumptions are made when the LSP is created. (1) Switching capabilities of outgoing links from the ingress and egress nodes (link1-2 and link4-3 in Figure 2) must be1) are consistent with each other. (2) Switching capabilities of all transit links including incoming links to the ingress and egress nodes (link2-1 and link3-4) should beare consistent with switching type of a LSP to be created. (3) Encoding-types of all transit links should beare consistent with encoding type of a LSP to be created. [CSPF] indicates the possible tables of switching capability, encoding type and bandwidth at the ingress link, transiting links and the egress link which need to be satisfied with GMPLS path computation of the created LSP. The non-packet GMPLSGMPLS-controlled networks (e.g., GMPLS-based TDM networks) are usually responsible for transmitting data for the client layer. These GMPLSGMPLS-controlled networks can provide different types of connections for customer services based on different service bandwidth requests. The applications and the corresponding additional requirements for applying PCE to non-packet networks,to, for example, GMPLS-based TDM networks, are described in Figure 3.2. In order to simplify the description, this document just discusses the scenario in SDH networks as an example. The scenarios in SONET or G.709 ODUk layer networks are similar to this scenario. N1 N2 +-----+ +------+ +------+ | |-------| |--------------| | +-------+ +-----+ | |---| | | | | A1 +------+ | +------+ | | | | | +-------+ | | | PCE | | | | +------+ | | | | | | | |-----| | | +------+ | | | N5 | | | | | +------+ +------+ | | | | +-----+ | |--------------| |--------| | +------+ +------+ +-----+ N3 N4 A2 Figure 3:2: A simple TDM(SDH)TDM (SDH) network Figure 32 shows a simple TDM(SDH)TDM (SDH) network topology, where N1, N2, N3, N4 and N5 are all SDH switches. Assume that one Ethernet service with 100M bandwidth is required from A1 to A2 over this network. The client Ethernet service could be provided by a VC4 connection from N1 to N4, and it could also be provided by three concatenated VC3 connections (Contiguous or Virtual concatenation) from N1 to N4. In this scenario, when the ingress node (e.g., N1) receives a client service transmitting request, the type of connections (one VC4 or three concatenated VC3) could be determined by PCC (e.g., N1 or NMS), but could also be determined by PCE automatically based on policy [RFC5394]. If it is determined by PCC, PCC should be capable of specifying the ingress node and egress node, signal type, the type of the concatenation and the number of the concatenation in a PCReq message. PCE should consider those parameters during path computation. The route information (co-route or separated-route) should be specified in a PCRep message if path computation is performed successfully. 3.3.As described above, PCC should be capable of specifying TE attributes defined in the next section and PCE should compute a path accordingly. Where a GMPLS network is consisting of inter-domain (e.g., inter-AS or inter-area) GMPLS-controlled networks, requirements on the path computation follows [RFC5376] and [RFC4726]. 2.2. Unnumbered InterfacesInterface GMPLS supports unnumbered interface ID that is defined in [RFC 3477],[RFC3477], which means that the endpoints of the path may be unnumbered. It should also be possible to request a path consisting of the mixture of numbered links and unnumbered links, or a P2MP path with different types of endpoints. Therefore, the PCC should be capable of indicating the unnumbered interface ID of the endpoints in the PCReq message. 184.108.40.206. Asymmetric Bandwidth Path Computation As per [RFC6387], GMPLS signaling can be used for setting up an asymmetric bandwidth bidirectional LSP. If a PCE is responsible for the path computation, the PCE should be capable of computing a path for the bidirectional LSP with asymmetric bandwidth. It means that the PCC should be able to indicate the asymmetric bandwidth requirements in forward and reverse directions in the PCReq message. 4.3. Requirements for GMPLS application of PCE In this section, we describe requirements for GMPLS applications of PCE in order to establish GMPLS LSP. 220.127.116.11. Requirements ofon Path Computation Request As for path computation in GMPLSGMPLS-controlled networks as discussed in section 3,2, the PCE should consider the GMPLS TE attributes appropriately according to tables in [CSPF]once a PCC or another PCE requests a path computation. Indeed, the path calculation request message from the PCC or the PCE must contain the information specifying appropriate attributes. According to [RFC5440],[PCEP-EXT],[ PCE- WSON-REQ][RFC5440], [PCE-WSON-REQ] and to RSVP procedures like explicit label control(ELC),the additional attributes introduced are as follows: [RFC5440](1) Switching capability: PSC1-4, L2SC, DCSC [RFC6002], EVPL [RFC6004], 802_1 PBB-TE [RFC6060], TDM, lambda, LSC, FSC (2) Encoding type: as defined in [RFC4202], [RFC4203], e.g., Ethernet, SONET/SDH, Lambda, etc. (3) Signal Type: Indicates the type of elementary signal that constitutes the requested LSP. A lot of signal types with different granularity have been defined in SONET/SDH and G.709 ODUk, such as VC11, VC12, VC2, VC3 and VC4 in SDH, and ODU1, ODU2 and ODU3 in G.709 ODUk. See[RFC4606] , [RFC4328]andSee [RFC4606], [RFC4328] and [OSPF-G709] or [RSVP-TE- G709].[RSVP-TE-G709]. (4) Concatenation Type: In SDH/SONET and G.709 ODUk networks, two kinds of concatenation modes are defined: contiguous concatenation which requires co-route for each member signal and requires all the interfaces along the path to support this capability, and virtual concatenation which allows diverse routes for the member signals and only requires the ingress and egress interfaces to support this capability. Note that for the virtual concatenation, it also may specify co-routed or separated-routed. See [RFC4606] and [RFC4328] about concatenation information. (5) Concatenation Number: Indicates the number of signals that are requested to be contiguously or virtually concatenated. Also see [RFC4606] and [RFC4328]. (6) Technology specificTechnology-specific label(s) such as wavelength label as defined in [RFC6205], or labelsdefined in [RFC4606], [RFC6060][RFC6060], [RFC6002] or [RFC6002].[RFC6205]. (7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1 protection, 1:1 protection, (pre-planned) rerouting, etc. (8) Administrative group: as defined in [RFC3630].[RFC3630] (9) Link Protection type: as defined in [RFC4203].[RFC4203] (10)Support for unnumbered interfaces: as defined in [RFC3477].[RFC3477] (11)Support for asymmetric bandwidth request: as defined in [RFC6387].[RFC6387] (12)Support for explicit label control during the path computation. (13) The PCC/PCE should be able to provide(13)Support of label restrictions similar to RSVP onin the requests/responses 4.2.requests/responses, similarly to RSVP-TE ERO and XRO as defined in [RFC3473] and [RFC4874]. 3.2. Requirements ofon Path Computation Reply As described above, a PCC must support to initiate a PCReq message specifying above mentioned attributes. ThePCE should compute the path that satisfies the constraints which are specified in the PCReq message. Then the PCE should send a PCRep message including the computation result to the PCC. For Path Computation Reply message (PCRep) in GMPLS networks, there are some additional requirements. The PCEP PCRep message must be extended to meet the following requirements. (1) Concatenation pathPath computation with concatenation In the case of concatenationpath computation,computation involving concatenation, when a PCE receives the PCReq message specifying the concatenation constraints described in section 4.1,3.1, the PCE should compute thea path which satisfies the specified concatenation constraints.accordingly. For contiguous concatenationpath computation, the routes of each member signal must be co-routedcomputation involving contiguous concatenation, a single route is required and all the interfaces along the route should support contiguous concatenation capability. Therefore, the PCE should compute a path based on the contiguous concatenation capability of each interface and only one ERO which should carry the route information for the response. For virtual concatenationpath computation,computation involving virtual concatenation, only the ingress/egress interfaces need to support virtual concatenation capability and maybethere aremay be diverse routes for the different member signals. Therefore, multiple EROs may be needed for the response. Each ERO may represent the route of one or multiple member signals. In the case thatwhere one ERO represents several member signals among the total member signals, the number of member signals along the route of the ERO must be specified. (2) Label constraint In the case that a PCC doesn'tdoes not specify the labelexact label(s) when requesting a label-resctricted path and the PCE is capable of performing the route computation and label assignment computation procedure, the PCE needs to be able to specify the label of the path in a PCRep message. Wavelength restriction is a typical case of label restriction but is only one instance of it.restriction. More generally in GMPLSGMPLS-controlled networks label switching and selection constraintconstraints may apply and a PCC may request a PCE to take label constraint into account and return an ERO containing the labelslabel or set of label that fulfillfulfil the PCC request. The PCReq aspects are covered in section 4.1 in the requirements 6, 12 and 13.(3) Roles of the routes When a PCC specifies the protection type of an LSP, the PCE should compute the working route and the corresponding protection route(s). Therefore, the PCRep should be capable of indicating which one isallow to distinguish the working or(nominal) and the protection route. 4.3.routes. 3.3. GMPLS PCE Management PCE relatedPCE-related Management Information Bases must consider extensions to be satisfied with requirements for GMPLS applications. For extensions, [RFC4802] are defined to manage TE database and may be referred to so as to accommodate GMPLS TE attributes in the PCE. 5.4. Security consideration PCEConsiderations PCEP extensions to support GMPLS should be considered under the same security as current PCE work. This extension will not change the underlying security issues. 6.5. IANA Considerations This document has no actions for IANA. 7.6. Acknowledgement The author would like to express the thanks to Ramon Casellas, Julien Meulic and Shuichi Okamoto for their comments. 8.7. References 18.104.22.168. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (MPLS) Signaling Functional Description", RFC 3471, January 2003.[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (MPLS)(GMPLS) Signaling -Resource ReserVation Protocol TrafficProtocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3477] K.Kompella,et al,"SignallingKompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol-Traffic Engineering(RSVP-TE)",JanuaryProtocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [RFC3630] Katz, D., Kompella, K., and D. Katz et al.,Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC3630,RFC 3630, September 2003. [RFC3945] E.Mannie, et al,E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC3945, October,RFC 3945, October 2004. [RFC4202] K.Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", RFC4202, Oct.Switching (GMPLS)", RFC 4202, October 2005. [RFC4203] K.Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching", RFC4203, Oct.Switching (GMPLS)", RFC 4203, October 2005. [RFC4328] D.Papadimitriou, Ed.,D., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC4328,RFC 4328, January 2006. [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 6387, September 2011.[RFC4606] Mannie, E. Mannieand D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC4606,RFC 4606, August 2006. [RFC4802] Nadeau, T. Nadeauand A. Farrel, Ed.,"Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC4802, Feb.RFC 4802, February 2007. [RFC4872] J.P.Lang, Ed.,J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to- EndEnd-to-End Generalized Multi-ProtocolMulti- Protocol Label Switching (GMPLS) Recovery", RFC4872,RFC 4872, May 2007. [RFC5440] J.P. Vasseur, et al,[RFC4927] Le Roux, J., "Path Computation Element (PCE)Communication Protocol (PCEP)", RFC5440, March 2009. [RFC6002] Lou Berger, et al.,"Generalized(PCECP) Specific Requirements for Inter-Area MPLS (GMPLS) Data Channel Switching Capable (DCSC)and Channel Set Label Extensions", RFC6002, OctoberGMPLS Traffic Engineering", RFC 4927, June 2007. [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC6002] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions", RFC 6002, October 2010. [RFC6004] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching", RFC 6004, October 2010. [RFC6060] DonFedyk, et al.,D., Shah, H., Bitar, N., and A. Takacs, "Generalized Multiprotocol Label Switching (GMPLS) controlControl of Ethernet PBB-TE", RFC6060,Provider Backbone Traffic Engineering (PBB-TE)", RFC 6060, March 2011. [RFC6205] T.Otani, Ed.,T. and D. Li, "Generalized Labels for G.694Lambda- Switching CapableSwitch-Capable (LSC) Label Switching Routers", RFC6205,RFC 6205, March 20112011. [RFC6387] Takacs, et. al.,A., Berger, L., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC6387,RFC 6387, September 2011 8.2.2011. 7.2. Informative References [OSPF-G709] Ceccarelli, D., "Traffic Engineering Extensions to OSPF for Generalized MPLS(GMPLS) Control of Evolving G.709 OTN Networks", draft-ietf-ccamp-gmpls-ospf-g709v3-05 (work in progress), January 2013. [PCE-WSON-REQ] Lee, Y., Bernstein, G., Martensson, J., Takeda, T., Tsuritani, T., and O. de Dios, "PCEP Requirements for WSON Routing and Wavelength Assignment", draft-ietf-pce-wson-routing-wavelength-08 (work in progress), October 2012. [RFC4216] Zhang, R. Zhan, et al,and J. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC4216,RFC 4216, November 2005. [RFC4655] A.Farrel, et al,A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC4655, Aug.,RFC 4655, August 2006. [RFC4657] J.Ash, et al,J. and J. Le Roux, "Path computation elementComputation Element (PCE) communication protocol generic requirements", RFC4657, Sept., 2007.Communication Protocol Generic Requirements", RFC 4657, September 2006. [RFC4726] A.Farrel, et al,A., Vasseur, J., and A. Ayyangar, "A frameworkFramework for inter-domain MPLS traffic engineering", RFC4726,Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006. [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. [RFC5394] I. Bryskin et al.,Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC5394,RFC 5394, December 2008. [RFC6457] T.Takeda,et al,"PCC-PCETakeda, T. and A. Farrel, "PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Engineering",RFC6457,December 2011. [CSPF] T. Otani, et al, "Considering Generalized Multiprotocol Label SwitchingTraffic Engineering Attributes During Path Computation", draft-otani-ccamp-gmpls-cspf-constraints- 07.txt, Feb., 2008. [PCEP-EXT] C.Margaria,et al, "PCEP extensions for GMPLS",draft-ietf- pce-gmpls-PCEP-EXTs, in progress. [PCE-WSON-REQ] Y.Lee, et al,"PCEP Requirements for WSON Routing and Wavelength Assignment",draft-ietf-pce-wson-routing- wavelength, in progress. [OSPF-G709] D.Ceccarelli,et al,"Traffic Engineering Extensions to OSPF for Generalized MPLS(GMPLS) Control of Evolving G.709 OTN Networks", in progress.Engineering", RFC 6457, December 2011. [RSVP-TE-G709] Fatai Zhang,et al,"GeneralizedZhang, F., "Generalized Multi-Protocol Label Switching(GMPLS)Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport NetworkNetworks Control", draft-ietf-ccamp-gmpls-signaling-g709v3-06 (work in progress. 9.progress), January 2013. Authors' Addresses Tomohiro Otani KDDI Corporation 2-3-2 Nishi-shinjuku Shinjuku-ku, Tokyo 163-8003Japan Phone: +81-3-3347-6006+81-(3) 3347-6006 Email: firstname.lastname@example.org Kenichi Ogaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino-shi,Kamifukuoka, Saitama 356-8502Japan Phone: +81-49-278-7897+81-(49) 278-7897 Email: email@example.com Diego Caviglia Ericsson 16153 Genova Cornigliano, ITALYCornigliano Italy Phone: +390106003736 Email: firstname.lastname@example.org Fatai Zhang Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang DistrictDistrict, Shenzhen 518129 P.R.China Phone: +86-755-28972912 Email: email@example.com Cyril Margaria Nokia Siemens Networks Optical GmbH St Martin Strasse 76 Munich, 81541 Germany Phone: +49 89 5159 16934 Email: firstname.lastname@example.org 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 email@example.com. 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. 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) 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.