idnits 2.17.1 draft-otani-pce-gmpls-aps-req-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 214. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 221. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 227. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2008) is 5768 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Unexpected draft version: The latest known version of draft-otani-ccamp-gmpls-cspf-constraints is -07, but you're referring to -08. == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-12 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Tomohiro Otani 3 Intended status: Informational Kenichi Ogaki 4 Expires:Jan. 2009 KDDI R&D Labs 5 Diego Caviglia 6 Ericsson 7 July 11, 2008 9 Requirements for GMPLS applications of PCE 11 Document: draft-otani-pce-gmpls-aps-req-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 The initial effort of PCE WG is specifically focused on MPLS (Multi- 37 protocol label switching). As a next step, this draft describes 38 functional requirements for GMPLS (Generalized MPLS) application of 39 PCE (Path computation element). 41 Table of Contents 43 Status of this Memo................................................ 1 44 Abstract........................................................... 1 45 1. Introduction.................................................... 3 46 2. Conventions used in this document............................... 3 47 3. GMPLS applications of PCE....................................... 3 48 4. Requirement for GMPLS application of PCE........................ 4 49 5. Security consideration.......................................... 5 50 6. IANA Considerations............................................. 5 51 7. Acknowledgement................................................. 5 52 8. Intellectual property considerations............................ 5 53 9. Informative references.......................................... 6 54 Author's Addresses................................................. 7 55 Document expiration................................................ 7 56 Copyright statement................................................ 7 57 1. Introduction 59 The initial effort of PCE WG is focused on solving the path 60 computation problem over domains in MPLS networks. As the same case 61 with MPLS, service providers (SPs) have also come up with 62 requirements for path computation in GMPLS networks such as photonics, 63 TDM-based or Ethernet-based networks as well. 65 [PCE-ARCH] and [PCECP-REQ] discuss the framework and requirements for 66 PCE on both packet MPLS networks and (non-packet switch capable) 67 GMPLS networks. This document complements these documents by 68 providing some consideration of GMPLS applications in the inter- 69 domain networking environment and indicating a set of requirements 70 for the extended definition of series of PCE related protocols. 72 Constraint based shortest path first (CSPF) computation within a 73 domain or over domains for signaling GMPLS Label Switched Paths 74 (LSPs) is more stringent than that of MPLS LSPs [MPLS-AS], because 75 the additional constraints, e.g., interface switching capability, 76 link encoding, link protection capability and so forth need to be 77 considered to establish GMPLS LSPs [CSPF]. GMPLS signaling protocol 78 [RFC3471, RFC3473] is designed taking into account bi-directionality, 79 switching type, encoding type, SRLG, and protection attributes of the 80 TE links spanned by the path, as well as LSP encoding type and 81 switching type for the end points, appropriately. 83 This document provides the investigated results of GMPLS applications 84 of PCE especially for the support of GMPLS inter-domain path 85 computation. This document also outlines GMPLS inter-domain 86 architecture, and provides requirements for GMPLS applications of PCE 87 in the GMPLS inter-domain environment. 89 2. Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC-2119 [RFC2119]. 95 3. GMPLS applications of PCE 97 3.1 GMPLS network model 99 Figure 1 depicts a typical network, consisting of several GMPLS 100 domains, assumed in this document. D1, D2, D3 and D4 have multiple 101 GMPLS inter-domain connections, and D5 has only one GMPLS inter- 102 domain connection. These domains follow the definition in [RFC4726]. 104 +---------+ 105 +---------|GMPLS D2|----------+ 106 | +----+----+ | 107 +----+----+ | +----+----+ +---------+ 108 |GMPLS D1| | |GMPLS D4|---|GMPLS D5| 109 +----+----+ | +----+----+ +---------+ 110 | +----+----+ | 111 +---------|GMPLS D3|----------+ 112 +---------+ 114 Figure 1: GMPLS Inter-domain network model. 116 Each domain is configured using various switching and link 117 technologies defined in [Arch] and an end-to-end route needs to 118 respect TE link attributes like multiplexing type, encoding type, 119 etc., making the problem a bit different from the case of classical 120 (packet) MPLS. In order to route from one GMPLS domain to another 121 GMPLS domain appropriately, each domain manages traffic engineering 122 database (TED) by PCE, and exchanges or provides route information of 123 paths, while concealing its internal topology information. 125 3.2 Path computation in GMPLS network 127 [CSPF] describes consideration of GMPLS TE attributes during path 128 computation. 130 Ingress Transit Egress 131 +-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+ 132 |Node1|------------>|Node2|------------>|Node3|------------>|Node4| 133 | |<------------| |<------------| |<------------| | 134 +-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+ 136 Figure 2: Path computation in GMPLS networks. 138 For the simplicity in consideration, the below basic assumptions are 139 made when the LSP is created. 141 (1) Switching capabilities of outgoing links from the ingress 142 and egress nodes (link1-2 and link4-3 in Figure .) must be 143 consistent with each other. 144 (2) SC of all transit links including incoming links to the 145 ingress and egress nodes (link2-1 and link3-4) should be 146 consistent with switching type of a LSP to be created. 147 (3) Encoding-types of all transit links should be consistent 148 with encoding type of a LSP to be created. 150 [CSPF] indicates the possible table of switching capability, encoding 151 type and bandwidth at the ingress link, transiting links and the 152 egress link which need to be satisfied with the created LSP. 154 4. Requirement for GMPLS application of PCE 156 In this section, we describe requirements for GMPLS applications of 157 PCE in order to establish GMPLS LSP over domains. 159 4.1 PCE requirements 160 As for path computation in GMPLS networks as discussed in section 3, 161 the PCE needs to consider the GMPLS TE attributes appropriately 162 according to tables in [CSPF] once a PCC or another PCE requests a 163 path computation. Indeed, the path calculation request message from 164 the PCC or the PCE needs to contain the information specifying 165 appropriate attributes. Additional attributes to those already 166 defined in [PCECP] are as follows. 168 (1) Switching capability: PSC1-4, L2SC, TDM, lambda, LSC, FSC 169 (2) Encoding type: as defined in [RFC4202], [RFC4203], e.g., Ethernet, 170 SONET/SDH, Lambda, etc. 171 (3) e2e Path protection type: as defined in [RFC4872], e.g., 1+1 172 protection, 1:1 protection, (pre-planned) rerouting, etc. 173 (4) Administrative group: as defined in [RFC3630] 174 (5) Link Protection type: as defined in [RFC4203] 176 4.2 PCC requirements 178 As described above, a PCC needs to support to initiate path 179 computation request specifying abovementioned attributes. Afterwards, 180 GMPLS signaling will be invoked according to the responded messages 181 from the PCE. 183 4.3 GMPLS PCE Management 185 PCE related Management Information Bases need to consider extensions 186 to be satisfied with requirements for GMPLS applications. For 187 extensions, [GMPLS-TEMIB] are defined to manage TE database and may 188 be referred to accommodate GMPLS TE attributes in the PCE. 190 5. Security consideration 192 PCE extensions to support GMPLS should be considered under the same 193 security as current work. This extension will not change the 194 underlying security issues. 196 6. IANA Considerations 198 This document has no actions for IANA. 200 7. Acknowledgement 202 The author would like to express the thanks to Shuichi Okamoto for 203 his comments. 205 8. Intellectual property considerations 207 The IETF takes no position regarding the validity or scope of any 208 Intellectual Property Rights or other rights that might be claimed to 209 pertain to the implementation or use of the technology described in 210 this document or the extent to which any license under such rights 211 might or might not be available; nor does it represent that it has 212 made any independent effort to identify any such rights. Information 213 on the procedures with respect to rights in RFC documents can be 214 found in BCP 78 and BCP 79. 216 Copies of IPR disclosures made to the IETF Secretariat and any 217 assurances of licenses to be made available, or the result of an 218 attempt made to obtain a general license or permission for the use of 219 such proprietary rights by implementers or users of this 220 specification can be obtained from the IETF on-line IPR repository at 221 http://www.ietf.org/ipr. 223 The IETF invites any interested party to bring to its attention any 224 copyrights, patents or patent applications, or other proprietary 225 rights that may cover technology that may be required to implement 226 this standard. Please address the information to the IETF at ietf- 227 ipr@ietf.org. 229 9. Informative references 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, March 1997. 232 [PCE-ARCH] A. Farrel, et al, "A Path Computation Element (PCE)- 233 Based Architecture", RFC4655, Aug., 2006. 234 [PCECP-REQ] J. Ash, et al, "Path computation element (PCE) 235 communication protocol generic requirements", RFC4657, 236 Sept., 2007. 237 [MPLS-AS] R. Zhan, et al, "MPLS Inter-Autonomous System (AS) 238 Traffic Engineering (TE) Requirements", RFC4216, 239 November 2005. 240 [CSPF] T. Otani, et al, "Considering Generalized 241 Multiprotocol Label Switching Traffic Engineering 242 Attributes During Path Computation", draft-otani- 243 ccamp-gmpls-cspf-constraints-08.txt, Feb., 2008. 244 [RFC3471] Berger, L., "Generalized Multi-Protocol Label 245 Switching (MPLS) Signaling Functional Description", 246 RFC 3471, January 2003. 247 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 248 Switching (MPLS) Signaling - Resource ReserVation 249 Protocol Traffic Engineering (RSVP-TE) Extensions", 250 RFC 3473, January 2003. 251 [RFC4726] A. Farrel, et al, "A framework for inter-domain MPLS 252 traffic engineering", RFC4726, November 2006. 253 [Arch] E. Mannie, et al, "Generalized Multi-Protocol Label 254 Switching Architecture", RFC3945, October, 2004. 255 [PCECP] J.P. Vasseur, et al, "Path Computation Element (PCE) 256 Communication Protocol (PCEP)", draft-ietf-pce-pcep- 257 12.txt, March 2008. 258 [RFC4202] K. Kompella, and Y. Rekhter, "Routing Extensions in 259 Support of Generalized Multi-Protocol Label 260 Switching", RFC4202, Oct. 2005. 262 [RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in 263 Support of Generalized Multi-Protocol Label 264 Switching", RFC4203, Oct. 2005. 265 [RFC4872] J.P. Lang, Ed., "RSVP-TE Extensions in Support of 266 End-to-End Generalized Multi-Protocol Label Switching 267 (GMPLS) Recovery", RFC4872, May 2007. 268 [GMPLS-TEMIB] T. Nadeau and A. Farrel, Ed., "Generalized 269 Multiprotocol Label Switching (GMPLS) Traffic 270 Engineering Management Information Base", RFC4802, 271 Feb. 2007. 272 [RFC3630] D. Katz et al, "Traffic Engineering (TE) Extensions 273 to OSPF Version 2", RFC3630, September 2003. 275 Author's Addresses 277 Tomohiro Otani 278 KDDI R&D Laboratories, Inc. 279 2-1-15 Ohara Kamifukuoka Saitama, 356-8502. Japan 280 Phone: +81-49-278-7357 281 Email: otani@kddilabs.jp 283 Kenichi Ogaki 284 KDDI R&D Laboratories, Inc. 285 2-1-15 Ohara Kamifukuoka Saitama, 356-8502. Japan 286 Phone: +81-49-278-7897 287 Email: ogaki@kddilabs.jp 289 Diego Caviglia 290 Ericsson 291 16153 Genova Cornigliano, ITALY 292 Phone: +390106003736 293 Email: diego.caviglia@ericsson.com 295 Document expiration 297 This document will be expired in January 31, 2009, unless it is 298 updated. 300 Copyright statement 302 Copyright (C) The IETF Trust (2008). 304 This document is subject to the rights, licenses and restrictions 305 contained in BCP 78, and except as set forth therein, the authors 306 retain all their rights. 308 This document and the information contained herein are provided on an 309 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 310 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 311 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 312 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 313 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 314 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.