idnits 2.17.1 draft-hayata-ipo-carrier-needs-00.txt: ** The Abstract section seems to be numbered -(130): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(254): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(279): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 8 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 400 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 14 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 59 has weird spacing: '...AL" in this ...' == Line 131 has weird spacing: '... in the netwo...' == Line 138 has weird spacing: '...carrier alway...' == Line 152 has weird spacing: '...As discussed ...' == Line 153 has weird spacing: '...within a netw...' == (14 more instances...) == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Hirokazu Ishimatsu 2 Internet-Draft Yoshihiro Hayata 3 Susumu Yoneda 4 Japan Telecom Co., LTD. 6 Expiration Date: May 2001 Ramesh Bhandari 7 George Newsome 8 Eve Varma 9 Lucent Technologies 11 November, 2000 13 Carrier Needs Regarding Survivability and Maintenance for 14 Switched 15 Optical Networks 17 draft-hayata-ipo-carrier-needs-00.txt 19 Status of this Memo 21 This document is an Internet-Draft and is in full 22 conformance with all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet 25 Engineering Task Force (IETF), its areas, and its working 26 groups. Note that other groups may also distribute working 27 documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of 30 six months and may be updated, replaced, or obsoleted by 31 other documents at any time. It is inappropriate to use 32 Internet-Drafts as reference material or to cite them other 33 than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be 39 accessed at http://www.ietf.org/shadow.html. 41 1. Abstract 43 As discussed in [1], the need for survivable optical networks is 44 critical, and introducing capabilities that further enhance network 45 survivability continues to be an essential objective. This is 46 particularly important for operators with stringent requirements for 47 network resilience and service survivability. However, disruption of 48 service can result not only from faults, but also from scheduled 49 maintenance procedures. This draft introduces some additional 50 considerations and carrier needs related to failure recovery and 51 scheduled maintenance work in switched optical networks. These are of 52 critical importance for serving -business customers who require super 53 high quality service assurance and pay correspondingly high tariffs in 54 order to guarantee this level of QoS. 56 2. Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 58 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 59 "OPTIONAL" in this document are to be interpreted as 60 described in RFC-2119. 62 3. Introduction 64 The explosion of data services is increasingly imposing challenging 65 network infrastructure requirements at the same time that wavelength 66 services are emerging in the marketplace. Next generation optical 67 networking solutions must enable scalable, flexible, and reliable 68 networks as well as increased responsiveness to client network needs. 69 Provision of an optical layer service framework has been discussed in 70 the context of service considerations considered important for inter- 71 city network operators [2]. As described in this material, some key 72 objectives include service functionality, a workable business model, and 73 evolvability in a heterogeneous network environment. 75 Key service functionality cited in [2] has included rapid provisioning 76 and restoration. Automated provisioning of optical layer resources in 77 support of scheduled and demand-based customer/client needs offers 78 opportunities for supporting new services as well as handling routine 79 maintenance activities in a non-service disrupting manner (e.g., 80 scheduled or predictable maintenance-related churn). 82 Assuring support for a workable business model that can adapt to change, 83 e.g., arbitrage, is important. In particular, it has become clear that 84 there is a range of reasonable business models that might be utilized in 85 an operator's network, depending upon the scope and objectives of the 86 enterprise. In particular, as discussed in [4], such models might be 87 used in various ways, and for various purposes, even by different 88 organizations within the same network operator domain. 90 Evolvability is an important consideration as it is essential for 91 service providers to have a smooth network evolution path for addressing 92 the unique problems inherent in simultaneously supporting an existing 93 network while deploying a new multi-service infrastructure. Clearly, it 94 is also necessary to enable emergent service providers to optimally 95 tailor their networks for their targeted market and service offerings; 96 however, emergent providers quickly need to deal with embedded base as 97 soon as initial deployment of resources has occurred. 99 Within the remainder of this draft, we will focus upon service 100 functionality and business model objectives in relation to service 101 survivability and maintenance considerations for highly reliable 102 services such as the super high quality services discussed below. 104 4. Switched Optical Services 106 The basic requirement of a switched optical service is that a channel is 107 established via an appropriate signaling mechanism before data can be 108 transferred and that this establishment is achieved in the following 109 manner: 110 - a real-time client specifies its traffic characteristics and its end- 111 to-end performance requirements to the server 112 - the most suitable route for a channel that meets these requirements is 113 determined 114 - translate the end-to-end parameters into local parameters at each NE 115 and attempt to reserve resources via signaling. 117 The service abstraction defines a contractual relationship between 118 client and server. Hence once the connection is established the server 119 guarantees in the absence of a failure that it will meet its contractual 120 obligations. This contract is basically agreed before data transfer. 121 When the server guarantees the contract, several actions have to be 122 taken in case of a failure. This paper addresses those actions in Sec. 123 4.2. 125 4.1 Super High Quality Services Characteristics 127 Super high quality services (also known as private line services) 128 offered by a carrier currently have the following characteristics: 130 - The exact physical and logical location of a private line user�s path 131 in the network is known and uniquely identifiable, (i.e. the optical 132 fiber cable, fiber, optical channel, SDH logical path, port of 133 transmission equipment/router, etc) is known to the network operator. 134 - When a logical path or port is switched to an alternate route (i.e., 135 a back-up path) due to an unexpected event, after the event or 136 failure is repaired, the carrier switches traffic back from the 137 alternate path to the original path. 138 - For scheduled maintenance, the carrier always asks customers having 139 super high quality services (that may be affected due to this 140 maintenance work) their preference in terms of when this work may be 141 carried out. The carrier then carries out the scheduled maintenance 142 work according to customer preference regarding date and time, as it 143 is essential that important customers not be adversely impacted in 144 any way by scheduled maintenance work. 145 - The carrier provides for guaranteed service survivability in the 146 event of failures. It does so by providing alternate paths for 147 carrying services, with the service and alternate paths being 148 physically and topologically diverse. 150 4.2 Service Survivability Considerations 152 As discussed in [3], there is a range of failures that can occur 153 within a network, and high reliability applications will require a 154 variety of failures to be taken into account. Examples that have been 155 considered include office outages, failures arising from diverse 156 circuits traversing shared protection facilities such as rings, and 157 natural disasters. It is essential to fully prepare for those natural 158 disasters such as earthquakes, volcanoes and typhoons. Further, for 159 super high quality services, there is extreme sensitivity to service 160 interruptions. Thus, it is important that the service and alternate 161 paths do not have links that are part of any Shared Risk Link 162 Groups (SRLG) [3], or pass through the same "region of failure". 163 Additionally, in order to assure an optimized survivable network 164 architecture, it is desirable that the alternate path can be switched- 165 back to the original service path once the failure is repaired (note 166 that not all carriers may choose to revert). The following different 167 grades of services may be defined with actions to be taken in the event 168 of a failure: 170 - Standard service, which is provided from a given source to a given 171 destination over a path computed in accordance with normal network 172 capacity constraints; when the customer loses connection on account 173 of a fault, the customer may request the same connection which the 174 network will then try to establish on a newly computed path. 176 - Medium High Quality Service which, at the customer�s request, 177 provides a connection over a path that avoids a certain set of cities 178 or regions, which are prone to damage due to natural disasters such 179 as earthquakes, volcanoes, typhoons, etc. These "regions of failure" 180 may each be ascribed a "radius of failure" determined from a study of 181 the past history of the spatial extent and severity of damage in 182 those regions; in the event of a failure of this service, the 183 customer may request reestablishment of a connection, which the 184 network will attempt to provide over a new path. 186 - High Quality Service, which is provided with a physically disjoint 187 back-up path in case of failure of the primary path; there are no 188 requirements on city avoidance, etc; as a result, the back-up 189 basically provides guarantee of continuity of service only in the 190 event of link or equipment failure. 192 - Super High Quality Service, which is provided with a physically 193 disjoint back-up path, constrained to have no "region of failure" in 194 common with the original path. Such type of service may be requested 195 by big business customers who essentially want continuity of service 196 at all times. In fact, since the downtime of the primary path may be 197 significantly large in major catastrophes such as those due to 198 earthquakes, floods, etc., a carrier may offer to provide a back-up 199 for the back-up over which the guaranteed services were switched upon 200 failure of the primary path. 202 The above four types of services may be summarized in the table below: 204 Service Type Physically disjoint Avoid a Region of 205 protection path Failure 207 Regular No No 208 Medium No Yes 209 High Yes No 210 Super High Yes Yes 212 In the event the constraints for the above high quality services can 213 only be met partially (e.g., 100% physical diversity between a given 214 pair of source and destination cannot be provided, e.g., because it just 215 does not exist for the particular source-destination pair), then the 216 customer, instead of being refused the desired service, may simply be 217 offered service with a correspondingly reduced level of service 218 protection; for example, if the percentage amount of fiber overlap on 219 the primary and secondary routes is x, then the customer may be offered 220 the service with a reduction in service continuity guarantee by x%, and 221 thus also with correspondingly reduced costs to the customer. 222 Furthermore, in those cases, where the customer does not want to pay the 223 full cost of the above high quality services, even when such service 224 exists, then service may still be provided, but with corresponding 225 reduced quality guarantees within the class of service under 226 consideration. 228 4.3 Data Bases and Algorithms 230 Because natural disasters such as earthquakes, typhoons, etc. can damage 231 a large area in one instance, it is important to ascertain the regions 232 within the service provider's network prone to damage by such 233 calamities. Normally, such areas have a history of damage, and it should 234 be possible to construct a data base on the location, intensity of 235 disaster, its frequency, and the size of the area affected; the area 236 affected may be expressed as a "radius of failure". It may also be 237 possible to use the information on the intensity of disaster and the 238 frequency of occurrence to assign probabilities of failure to the 239 offered services. For path computation, the following data bases are 240 needed: 242 - Nodes, links, and their fiber span content, or alternatively, nodes, 243 fiber spans and links riding the individual spans also called Shared 244 Risk Link Groups (SRLG's); clearly, if a link or node is not in 245 service, it is not included in path computation. 247 - Regions of failure, corresponding radii of failure and locations 248 within the service provider's network; these should be taken into 249 account before computing paths for the medium high and super high 250 quality services. 252 For highly reliable services such as the super high quality services, 253 physically-disjoint paths for real-life networks (which involve span- 254 sharing links or SRLG�s) are required. Ref. [5] describes algorithms for 255 such real-life networks. The algorithms emphasize optimality to save 256 network costs. Depending upon the span-sharing topologies of a given 257 network, these optimal algorithms can be very fast, and thus suitable 258 for running in the real-time environment. For networks, with very 259 complicated span-sharing topologies, exact algorithms do exist [5], but 260 they are slow for large networks, since the problem becomes NP-complete. 261 In such situations, fast heuristics may be developed [5] (see also [2] 262 for a discussion on diversity). 264 4.4 Business Model Considerations 266 As described in [4], there are several business models that may be 267 applicable for network operators: ISP owning all Layer 1 infrastructure 268 and only delivering IP-based services, ISP owning or leasing Layer 1 269 infrastructure and only delivering IP-based services, retailer or 270 wholesaler for multi-services, and a carrier�s carrier or bandwidth 271 broker. A carrier owns the layer 1 infrastructure and sells multiple 272 service types to customers, which may include other operator networks. 273 This bandwidth brokering, or reseller, role takes on a new meaning in 274 the context of service resilience. For many years, in Japan, operators 275 have collaborated to handle traffic in the event of natural disasters, 276 so that bandwidth can be borrowed from each other. Thus, if an operator 277 doesn�t have the capacity, they can borrow capacity from another 278 network. Accommodating the unexpected is a key factor in this case. 279 Indeed it seems to be a common pattern in industry that business�s that 280 provide service and operate their own infrastructure tend to separate 281 into two business�s. This makes it likely that even though 282 infrastructure may be whole owned today, it may well not be tomorrow. 283 This makes it important to take account of fully separated business 284 models (case 3 and 4 of [4]) even if this does not seem to represent the 285 majority of today's business's. 287 5. Implications for switched optical networks 289 Considering the discussion in Subsections 4.1 - 4.4, switched optical 290 networks must minimally: 291 - Support the various grades of high quality services, including the 292 Super High Quality Service described in Sec. 4.1. 293 - Support survivability considerations related to diverse routing, 294 tailored to the unique characteristics of Japan�s geography and 295 routing of fibers. 296 - Enable "bandwidth borrowing on demand" from other carriers as well as 297 support for multiple service types. 299 Examples of necessary functionality are provided in more detail below, 300 as well as some related connection setup operations. 302 5.1 Functions 304 - When referring to Section 4, we can see that the following functions 305 need to be supported: 306 - Ability for network operator to manually set the date and time that a 307 path switching function should take place, and have that occur 308 automatically. (The guarantee that the switch occurs as scheduled is 309 closely linked to resource allocation policies; see T1X1.5/2000-194 310 for further discussion on scheduled connections.) 311 - Ability to specify switching to a physically/topologically disjoint 312 path from the service path. 313 - Ability to maintain and update the data bases in a timely manner so 314 that a connection request is supported with the most current 315 knowledge of the network. 316 - Ability for operator to support a survivability policy that enables 317 the capability for switch-back to the original service path. 318 - Ability to support an operator policy to prioritize service requests 319 so that, in the event of a fault, customers with super high quality 320 services have first priority in being switched to disjoint paths. 321 - Ability to enable key customers to request constraints on the 322 connection path(e.g., avoid City X because an earthquake has just 323 occurred, or simply because the city is very much prone to damage 324 from natural disasters such as earthquakes, volcanoes and typhoons. 325 This involves the ability to express geographic constraints, as 326 opposed to just physical (equipment) or topological constraints. 327 - Ability to prevent new customers from being added to a particular 328 link for a certain amount of time (e.g., because of a failure, 329 natural disaster, scheduled maintenance). This requires the ability 330 to mark particular resources as out of service. 331 - Ability for the operator to query service management function to 332 establish the exact location and characteristics of service paths for 333 key customers. 334 - Ability for the operator to view information regarding which 335 customer/user is associated with which service path(s). 337 5.2 Connection Setup Operation 339 Referring to [4], some relevant connection setup parameters include: 341 1) Scheduled service - ability to request the connection to be made at 342 some specified time in the future (see T1X1.5/2000-194 for further 343 discussions). 344 2) Scheduled duration - ability to specify a duration for the 345 Connection. 346 3) Resilience - ability to request resilience against server layer 347 faults, and specify a particular degree of risk (see Sec. 4.2) 348 4) Connection Constraints - ability to specify the constraints as in the 349 three levels of high quality service described in Sec. 4.2. 351 6. References 353 [1] J. Luciani, B. Rajagopalan, D. Awduche, B. Cain, B. Jamoussi, "IP 354 over Optical Networks - A Framework", , March 2000 356 [2] John Strand, "Optical Layer Services Framework", T1X1.5/2000-142 357 [3] Monica Lazer, John Strand, "Some Routing Constraints", T1X1.5/2000- 358 143 359 [4] George Newsome, "ASON - Requirements at the Client API", 360 T1X1.5/2000-158 361 [5] Ramesh Bhandari, "Survivable Networks - Algorithms for Diverse 362 Routing", Kluwer Academic Publishers, 1999. 364 7. Authors' Contact Information 366 Hirokazu Ishimatsu 367 Japan Telecom 368 hirokazu@japan-telecom.co.jp 370 Yoshihiro Hayata 371 hayata@japan-telecom.co.jp 373 Sussumo Yoneda 374 Japan Telecom 375 yone@japan-telecom.co.jp 377 Ramesh Bhandari 378 Lucent Technologies 379 bhandari1@lucent.com 381 George Newsome 382 Lucent Technologies 383 gnewsome@lucent.com 385 Eve Varma 386 Lucent Technologies 387 evarma@lucent.com 389 Expiration Date: May 2001