idnits 2.17.1 draft-okamoto-ccamp-midori-gmpls-extension-reqs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 96 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 date (March 15, 2013) is 4058 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.winter-energy-effcient-internet' is mentioned on line 93, but not defined == Unused Reference: 'I-D.winter-energy-efficient-internet' is defined on line 255, but no explicit reference was found in the text -- No information found for draft-dong-panet-requirements - is the name correct? == Outdated reference: A later version (-07) exists of draft-retana-rtgwg-eacp-01 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Okamoto 3 Internet Draft Keio University 4 Intended status: Informational March 15, 2013 5 Expires: September 2013 7 Requirements of GMPLS Extensions for Energy Efficient Traffic 8 Engineering 9 draft-okamoto-ccamp-midori-gmpls-extension-reqs-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on September 15, 2013. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents carefully, 42 as they describe your rights and restrictions with respect to this 43 document. 45 Abstract 46 This document discusses some of extensions required in existing GMPLS 47 OSPF routing protocol, RSVP signaling protocol, and LMP to support 48 the energy efficient traffic engineering technology. 50 Table of Contents 52 1. Introduction ................................................ 2 53 1.1. Conventions used in this document ....................... 3 54 2. Energy efficient traffic engineering extensions .............. 3 55 2.1. TE link status ......................................... 3 56 2.2. LSP status ............................................. 4 57 2.3. Link power on/off control 58 ............................... 4 59 2.4. Notify control ......................................... 5 60 3. Security Considerations 61 ...................................... 5 62 4. IANA Considerations ......................................... 5 63 5. References .................................................. 5 64 5.1. Normative References 65 .................................... 5 66 5.2. Informative References 67 .................................. 6 68 6. Acknowledgments ............................................. 7 70 1. Introduction 72 The Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] 73 protocol suite is designed to provide a control plane for a range of 74 network technologies including packet/frame switching networks 75 including MPLS routers and Ethernet switches, optical networks such 76 as time division multiplexing (TDM) networks including SONET/SDH and 77 Optical Transport Networks (OTNs), and lambda switching optical 78 networks. 80 In GMPLS controlled networks, the network is described by label 81 switch routers (LSRs) and traffic engineering (TE) links. A TE link 82 is advertised as an adjunct to a "physical" link. When the link is up, 83 both the regular Internal Gateway Protocol (IGP) properties of the 84 link (basically, the Shortest Path First (SPF) metric) and the TE 85 properties of the link (such as bandwidth and switching capability) 86 are then advertised. Therefore, basically, if the link is down then 87 the TE link is also down. A TE link is not only defined between IGP 88 neighbors but also defined on a Forwarding Adjacency (FA) label 89 switched path (LSP). An LSP is composed with cross-connection of TE 90 links. Therefore, if the composed TE link is down then the LSP is 91 also down. 93 An energy efficient Internet [I-D.winter-energy-effcient-internet], a 94 power aware networking (PANET) [I-D.dong-panet-requirements], and an 95 energy aware control plane [I-D.retana-rtgwg-eacp] are discussed. 97 Energy efficient traffic engineering technology is also discussed in 98 [Yonezu][Cerutiti.ECOC][Cerutiti.JLT]. Under the energy efficient 99 traffic engineering, LSPs are rerouted to use lest number of links, 100 then some links are physically shutdown to reduce power consumption 101 of equipment. In traditional GMPLS networks, TE links associated in 102 shutdown links are also down. Therefore, when emergency occurred, 103 such as traffic explosion and link/equipment failure, downed TE links 104 are not able to use for calculating protection LSP and LSP rerouting. 106 This document defines requirements for extending GMPLS protocols to 107 support the energy efficient traffic engineering features. 109 1.1. Conventions used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC-2119 [RFC2119]. 115 2. Energy efficient traffic engineering extensions 117 Protocol extensions of OSPF, RSVP, and Link Management Protocol (LMP) 118 are required to support new TE link status, new LSP status, link 119 power on/off capability, and new notify control feature. 121 2.1. TE link status 123 [RFC2328] defines Interface states for describing "Interface State 124 changes" and "Interface State Machine". A link status "Up" and "Down" 125 can be get from the Interface states. 127 [RFC3630] defines the Traffic Engineering properties of TE links and 128 defines Link Type/Length/Value (TLV) for TE link properties 129 advertisement. A Link-TLV has some sub-TLVs, however, there is no TE 130 link status information. [RFC4203] adds some sub-TLVs to the Link-TLV 131 in support of GMPLS. 133 As a conclusion, a TE link does not have any status indication. If 134 Link becomes down then value(s) of the Traffic Engineering Metric 135 sub-TLV, and/or the Maximum bandwidth sub-TLV, and/or the Maximum 136 Reservable Bandwidth sub-TLV in associated TE links are changed 137 according with the network operator's policy. 139 Under the energy efficient TE environment, the link down by 140 administrative operation or link failure, and link power down by the 141 energy efficient TE should be distinguished in the route calculation 142 system such as Constraint Shortest Path First (CSPF) and Path 143 Computation Entity (PCE). 145 A TE link state sub-TLV which indicates power off state of the TE 146 link is required. 148 2.2. LSP status 150 [RFC3471], [RFC3473], and [RFC4974] defines the Administrative Status 151 Information in the Admin_Status object. The defined status bits are 152 Reflect (R), Testing (T), Administratively down (A), Deletion in 153 progress (D), and Call Management (C). 155 In the energy efficient TE environment, an LSP which includes power 156 off TE link(s) as LSP component can be defined. This LSP can be 157 assigned as a backup LSP. The backup LSP which does not contain power 158 of link(s) can be used as 1+1 protection, 1:N protection w/wo extra 159 traffic, shared protection, and restoration. On the other hand, the 160 backup LSP which contains power off link(s) can be used as 1:N 161 protection wo extra traffic, shared protection, and restoration. When 162 activating the LSP, power up of link(s) is required. 164 To distinguish the backup LSP which contains the power off link(s) or 165 not, new LSP status should be defined in the Admin_Status object. 167 2.3. Link power on/off control 169 The energy efficient TE requires link power on/off control function. 170 There are two possible implementation, one is using LMP the other is 171 using RSVP. 173 When using LMP, power on (or off) initiator LSR sends power on (or 174 off) request to the neighbor LSR. The neighbor LSR sends Ack to the 175 initiator LSR and power on (or off) the link and changes the TE link 176 status. Then the initiator LSR receives Ack and power on (or off) the 177 link and changes the TE link status. 179 The power control should be included to the LMP. 181 Note: to apply the power on procedure, IP control channel (IPCC) 182 should be always up. Therefore, a dedicated IPCC is required to apply 183 the LMP control. 185 When using RSVP, sequentially concatenated TE links can be controlled. 186 There are two procedure candidates in the power off procedure. 188 [Power On] All TE links along with the LSP are power on. 190 [Power Off] 191 1. All TE links along with the LSP are power off. If other LSPs share 192 the TE links then the LSPs should be rerouted. 194 2. All TE links but not shared by other LSPs are power off. 196 Both procedures are used according with the network operator's policy. 198 It may be required with LSP graceful shutdown procedure to notify the 199 link power off completion to the initiator. 201 Power control request may be implemented in the Admin_Status object. 203 2.4. Notify control 205 The power off procedure option #1 described in 2.3 can be applicable 206 not only to a single layer network but also to a multi-layer network. 207 If the server layer TE-link becomes the "power off" state, upper 208 layer LSP segment detects the status change and sends NOTIFY message 209 to an LSP ingress node. The ingress node reroutes the LSP or changes 210 the LSP status to "power off". 212 3. Security Considerations 214 TBD 216 4. IANA Considerations 218 TBD 220 5. References 222 5.1. Normative References 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, March 1997. 227 [RFC3945] Mannie, E. (Editor), "Generalized Multi-Protocol Label 228 Switching (GMPLS) Architecture", RFC 3945, October 2004. 230 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 232 [RFC3630] Katz, D., Kompella, K., Yeung, D., "Traffic Enginnering 233 (TE) Extensions to OSPF Version 2", RFC 3630, September 234 2003. 236 [RFC4203] Kompella, K., and Rekhter, Y. (Editors), "OSPF Extensions 237 in Support of Generalized Multi-Protocol Label Switching 238 (GMPLS)", RFC 4203, October 2005. 240 [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label 241 Switching (GMPLS) Signaling Functional Description", RFC 242 3471, January 2003. 244 [RFC3473] Berger, L. (Editor), "Generalized Multi-Protocol Label 245 Switching (GMPLS) Signaling Resource ReserVation Protocol- 246 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 247 January 2003. 249 [RFC4974] Papadimitriou, D., and Farrel, A., "Generalized MPLS 250 (GMPLS) RSVP-TE Signaling Extensions", RFC 4974, August 251 2007. 253 5.2. Informative References 255 [I-D.winter-energy-efficient-internet] Winter, R., Jeong, S., Choi, 256 JH., "Towards an Energy-Efficient Internet", draft-winter- 257 energy-efficient-internet-01.txt (work in progress), October 258 2012. 260 [I-D.dong-panet-requirements] Dong, J., Zhang, M., Zhang, B., 261 Boucadair, M., "Requirements for Power Aware Network", draft- 262 dong-panet-requirements-01.txt (work in progress), February 263 2013. 265 [I-D.retana-rtgwg-eacp] Retana, A., White, R., Paul, M., "A Framework 266 and Requirements for Energy Aware Control Planes", draft- 267 retana-rtgwg-eacp-01.txt (work in progress), February 2013. 269 [Yonezu] Yonezu, H., Kikuta, K., Ishii, D., Okamoto, S., Oki, E., and 270 Yamanaka, N., "QoS Aware Energy Optimal Network Topology Design 271 and Dynamic Link Power Management", Proc. ECOC 2010 Tu.3.D.4. 273 [Cerutiti.ECOC] 274 Cerutiti I., Sambo, N., and Castoldi, P., "Distributed 275 support of link sleep mode foe energy efficient GMPLS networks", 276 Proc. ECOC 2010 P5.11. 278 [Cerutiti.JLT] Cerutiti I., Sambo, N., and Castoldi, P., "Sleeping 279 Link Selection for Energy-Efficient GMPLS Networks", IEEE 280 Journal of Lightwave Technology, Vol. 29, No. 15, pp.2292-2298, 281 Aug. 2011. 283 6. Acknowledgments 285 The author would like to thank Prof. Naoaki Yamanaka and all members 286 of the Interoperability Working Group, Kei-han-na Open Laboratories 287 for their useful comments and suggestions. 289 Author's Addresses 291 Satoru Okamoto 292 Keio University 293 3-14-1 Hiyoshi, Kohoku-ku 294 Yokohama, Kanagawa 223-8522 Japan 295 Email: okamoto@ieee.org