idnits 2.17.1 draft-duroyon-te-ip-optical-01.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 18) being 60 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 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet has text resembling 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 (November 2000) is 8561 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Olivier Duroyon 3 Rudy Hoebeke 4 Hans De Neve 5 Dimitri Papadimitriou 6 Internet Draft Alcatel 7 Document: draft-duroyon-te-ip-optical-01.txt November 2000 8 Expiration Date: May 2001 10 G.LSP Service Model framework in an Optical G-MPLS network 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 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 1. Abstract 36 The objective of this draft is to propose an IP service model for a 37 non-packet switch capable optical network where G.LSPs are 38 dynamically triggered by the IP layer and subsequently advertised 39 for IP routing. The business model assumes that several IP service 40 domains, some of which represent different administrative entities, 41 share the same optical backbone and focuses therefore primarily on 42 an overlay model. G-MPLS signaling (refer to [g-mpls]) with UNI 43 support is assumed as underlying control plane protocol. 45 2. Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 Duroyon et al. Expires May 2001 1 50 draft-duroyon-te-ip-optical-01.txt November 2000 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 53 this document are to be interpreted as described in RFC2119. 55 3. Introduction 57 This draft introduces an end-to-end IP service model enabling the 58 dynamic management of Generalized Label Switched Paths (G.LSP) by 59 means of G-MPLS signaling with User-to-Network Interface (UNI) 60 support. A G.LSP is a point-to-point connectivity with specified 61 attributes (some of which are mandatory, while others are optional) 62 established between two termination points in the optical network. 63 A G.LSP could be a fiber switched path, a lambda switched path, a 64 TDM switched path (circuit) or a packet-switch capable G.LSP. The 65 scope of this draft is restricted to optical networks, which are by 66 definition non-packet switch capable. Consequently, G.LSPs are 67 restricted to non-packet switch capable G.LSPs, which we hereafter 68 refer to as G.LSPs. 70 For reasons of definiteness, the optical devices are always 71 referred to as Optical Network Elements (ONE) and the IP devices as 72 Client Network Elements (CNE). Boundary CNEs and boundary ONEs are 73 interconnected through an UNI signaling and routing interface. 74 The owner of the UNI interface in the optical domain (UNI-Network 75 or UNI-N) is referred to as in the Boundary ONE Controller (ONE-C). 76 Its counterpart in the Client Network (UNI-Client or UNI-C) is 77 referred to the Boundary CNE Controller (CNE-C). 79 The terminology used in the draft attempts to be in line with the 80 definitions found in [ip-optical], [ouni-framework] and 81 [OIF2000.125.2]. 83 An overlay use of G-MPLS (UNI support) is appropriate for an 84 untrusted environment where several IP service domains, 85 representing different administrative entities, share the same 86 optical backbone. Moreover, this model seems well suited for a 87 network architecture including non-IP devices, e.g., legacy TDM or 88 ATM equipment, that interface with the same optical backbone. This 89 is however beyond the scope of this draft. 91 To distinguish between trusted and untrusted peers, a separate 92 definition for a Trusted and Untrusted network interfaces is 93 proposed: 94 - An Untrusted interface is defined when UNI (respectively NNI) 95 interfaces belongs to distinct administrative authorities. For 96 instance an UNI interface between a client network element and an 97 optical network element belonging to distinct ISPs defines an 98 untrusted relationship between the client and the optical network 99 element. 100 - A Trusted interface is defined when UNI (respectively NNI) 101 interfaces belongs to the same administrative authority. For 102 instance an NNI interface between two ONEs belonging to the same 104 Duroyon et al. Expires May 2001 2 105 draft-duroyon-te-ip-optical-01.txt November 2000 107 optical carrier defines a trusted relationship between these 108 optical networks elements. 110 The service model further assumes that a decision point in the IP 111 service domain, e.g., a Traffic Engineering tool (TE tool), will 112 trigger a boundary CNE to issue a G.LSP request towards the optical 113 domain. The decision point determines the need for a G.LSP on the 114 basis of IP Service Level Agreements (IP SLAs) and related 115 information, such as for instance load measurements in the IP 116 service domain. 118 The same TE-tool may also decide about the configuration of Traffic 119 Engineering LSPs (TE-LSP), which are by definition Packet-switch 120 capable LSPs. For the purpose of IP traffic engineering, TE-LSPs 121 are in this case created on top of non-Packet-switch capable 122 G.LSPs. 124 In the remainder of the document, the terms TE tool or decision 125 point are used interchangeably and refer to the IP service domain 126 device, capable of triggering G.LSP requests. 128 4. IP service model description 130 This section outlines the sequence of events that characterize our 131 proposed IP service model. 133 (1) Configuration 135 Configuration consists of installing and configuring interfaces of 136 the boundary ONEs and boundary CNEs. 138 During this stage of end-points configuration, physical attributes 139 of the end-point (as protection attributes of the drop side) are 140 also configured. Configuration of the NNI interfaces of the ONEs is 141 out of the scope of this draft. 143 (2) Neighbor Discovery, Endpoint Registration and Service Discovery 145 The objective of Neighbor Discovery is to provide the information 146 needed to identify the neighbor identity and neighbor connectivity 147 over each link interconnecting a boundary CNE to a boundary ONE. 149 Endpoint registration is concerned with registering boundary CNE 150 endpoints to the optical network. The registration information 151 includes the resource capabilities, closed user group (CUG) 152 identification, port reachability information, UNI protection 153 capabilities etc. This set of information is critical to enable 154 dynamic G.LSP services at the UNI. The endpoint registration 155 mechanism enables the end system to register its critical set of 156 information so that other end systems can identify its existence 157 and network properties. 159 Duroyon et al. Expires May 2001 3 160 draft-duroyon-te-ip-optical-01.txt November 2000 162 Service discovery is concerned with obtaining the essential 163 information about services from the attached optical network that 164 are available for the CNE. This information is used by CNEs to 165 establish the service environment. The service discovery mechanism 166 allows the network element to convey information about available 167 services to the end system. 169 After finishing neighbor discovery, endpoint registration and 170 service discovery, each end system should establish the service 171 environment and have sufficient information to generate G.LSP 172 service request. These mechanisms complement each other and they do 173 not depend on the establishment and use of signaling channels 174 between the two parties. 176 (3) Optical Service Level Agreements 178 Next, the service model consists of negotiating Optical SLAs (O- 179 SLA) at optical network-client network boundaries, or between 180 optical networks. 182 In case of an untrusted peering relationship (i.e. untrusted UNI, 183 respectively NNI), each G.LSP request is authenticated and 184 validated against the O-SLA. The validation process against an O- 185 SLA includes checking whether the request is conforming to the 186 restrictions (e.g., on scope) defined in the O-SLA. 188 O-SLAs may also be defined at trusted interfaces as the optical 189 domain to provision resources that could use them. Trusted in this 190 context refers to the fact that you don't expect the CNE to violate 191 this O-SLA, and as such requests received from trusted neighbors 192 don't need to be validated against the O-SLA. 194 (4) G.LSP service request 196 The decision point of the client network determines the required 197 connectivity through the optical domain based on service 198 requirements as per the IP SLAs. It then triggers the boundary CNEs 199 to send a G.LSP service request towards the associated boundary 200 ONEs, using G-MPLS signaling with UNI support. This process is 201 dynamic and may involve, amongst others, the creation of additional 202 G.LSPs, the deletion of existing G.LSPs or the modification of 203 existing G.LSPs. 205 (5) Address resolution 207 At the UNI, the G.LSP service request sent by the CNE needs to 208 include the ONE source and destination termination-point 209 identifiers (in case of trusted UNI interface) or the CNE source 210 and destination termination-point identifiers (in case of untrusted 211 UNI interface). CNE termination-points should also be considered 212 when the G.LSP is established through several optical networks 213 belonging to different administrative authorities. 215 Duroyon et al. Expires May 2001 4 216 draft-duroyon-te-ip-optical-01.txt November 2000 218 Consequently, the source client needs to send an address resolution 219 request to obtain the ONE destination termination-point ID or CNE 220 termination-point ID corresponding to the CNE destination logical- 221 address of the G.LSP service request. 223 (6) Optical path selection 225 In case a dedicated instance of an IGP is used inside the optical 226 transport network, each boundary ONE learns the complete topology 227 of the optical domain. A Constraint-based Shortest Path First 228 (CSPF) algorithm can then be implemented in the boundary ONEs to 229 calculate a route for the G.LSP in line with the constraints 230 specified in the request. As an example, the route of a G.LSP may 231 depend on the protection requirements or routing constraints 232 specified in the G.LSP request. The latter may indicate that the 233 requested G.LSP should be routed diversely from other G.LSPs. This 234 CSPF algorithm is expected to be quite different from an IP CSPF 235 algorithm because of optical networking specific considerations. 237 (7) G.LSP advertisement to the IP layer 239 As soon as the G.LSPs are lit up, they are advertised to the client 240 network. The involved boundary CNEs will either create a new IP 241 link and start to exchange routing information (using IGP or eBGP) 242 or modify the characteristics of the existing IP link. 244 (8) Traffic engineering for optimization of the optical domain 246 Optionally, the optical domain may have its own off-line Optical 247 Traffic Engineering (O-TE) tool. This tool may be used for 248 optimization of resource utilization in the optical network by 249 rearranging some G.LSPs. 251 5. UNI discovery and registration services 253 In order to provide a flexible and end-to-end IP Service model, 254 with a minimum set of local provisioning, specific mechanisms and 255 procedures have to be defined at the boundary between the client 256 and the optical network: 257 - to discover neighbors identity and connectivity 258 - to register client end-point identity 259 - and to discover the supported UNI and network services. 261 Transport mechanisms used for the UNI discovery and registration 262 services are referenced in [OIF2000.125.2] and [OIF2000.200]. 264 5.1 Neighbor discovery at the UNI 266 The key objective of Neighbor Discovery at the UNI is to provide 267 the information needed to identify the neighbor identity (IP 268 address associated to the corresponding UNI) and neighbor 270 Duroyon et al. Expires May 2001 5 271 draft-duroyon-te-ip-optical-01.txt November 2000 273 connectivity over each link connecting the boundary CNE to the 274 boundary ONE. 276 Neighbor discovery process which is also referred to as the 277 Termination-port identity process, provides the following 278 information to the boundary CNE and ONE: 279 - the ONE discovers the identity of the client CNE by 280 automatically discovering the IPv4 address assigned to the UNI-C 281 and the identity of each physical port connected to the CNE 282 - the CNE discovers the identity of to the connected ONE by 283 automatically discovering the IPv4 address assigned to the UNI-N 284 and the identity of each physical port connected to the ONE 286 If the signaling transport mechanism is not explicitly configured, 287 the neighbor discovery process ends by the bootstrapping of the 288 signaling control-channel used to exchange the information during 289 the end-point registration and the service discovery processes. 291 5.2 End-point Registration and UNI Service Discovery 293 The end-point registration process includes the exchange of 294 information between the CNE and ONE for each of the ports and 295 logical ports connecting the CNE to the ONE. A logical port defines 296 the structure of a physical port by identifying for a given port 297 each of the channels included within this port and sub-channels 298 included within this channel. 300 The UNI Service discovery process includes the exchange of 301 resource-related information of the Framing and Bandwidth capacity 302 of each of the ports and logical ports connecting the CNE to the 303 ONE. Additional parameters, such as the UNI drop-side protection 304 attributes (UNI client-side protection and UNI network-side 305 protection) and the G.LSP Directionality support could also be 306 exchanged during the resource discovery process. For SDH/Sonet 307 interfaces, the Transparency levels (STE-C, LTE-C), the client 308 support of Virtual Concatenation (VC) and the levels of Continuous 309 Concatenation (CC). 311 The end-point registration process includes also the address 312 registration process [OIF2000.261.1]. The address registration 313 process allows the CNE to register the CNE logical addresses 314 attached to the CNE Termination-point ID to which corresponds an 315 unique ONE Termination-point IDs. A CNE Termination-point ID 316 includes the unique IP address associated with the client element 317 and the logical-port ID. The logical-port ID comprises the port-ID, 318 Channel-ID and Sub-channel-ID as defined in [OIF2000.125.2]. 320 When the address registration is part of the end-point registration 321 process, the CNE associates the CNE Termination-point ID with the 322 corresponding logical address and ONE termination-point ID. When 323 the CNE does not associate logical addresses with their interfaces, 325 Duroyon et al. Expires May 2001 6 326 draft-duroyon-te-ip-optical-01.txt November 2000 328 the CNE termination-point ID resolution implies that the boundary 329 ONE knows the mappings between the CNE termination-point ID and the 330 ONE termination-point ID. This case is considered as a particular 331 case where the CNE logical address fields are empty. In this case, 332 the value of the logical address could correspond to the user-group 333 identifier to which the G.LSP belongs; however, in this particular 334 case, the address resolution is always based on the CNE 335 termination-point ID. 337 Other client identifiers could be exchanged during end-point 338 registration process: 339 - the CNE registers the Contract ID attached to a specific element 340 and/or interface 341 - the CNE registers the Closed User-Group (CUG) IDs (i.e. User- 342 Group ID) attached to a specific client end-point or port 344 5.3 Network Service Discovery 346 The network service Discovery consists of the G.LSP service-related 347 discovery process and a policy related service discovery process. 349 During the G.LSP-related service discovery process, the CNE 350 registers and/or discovers the parameters related to 351 - SDH/Sonet related services, i.e., the SDH/Sonet Transparency 352 levels supported and the Continuous Concatenation levels 353 supported 354 - G.LSP Directionality support 355 - Network-side Protection, i.e., the Protection-levels services 356 provided by the internal optical network (Unprotected, Dedicated 357 1+1 Protection, Dedicated 1:1 and Shared Protection) 358 - G.LSP Priority classes and Preemption levels supported by the 359 optical network 360 - G.LSP Diversity options supported by the optical network 361 - Security levels support (IPSec or other authentication 362 mechanism) within the signaling used on the control-plane 363 throughout the optical network 365 The discovery of the Policy-related service may include the 366 following parameters: 367 - Service-levels offered by optical network 368 - Scheduling-related service supported by the optical transport 369 network and/or the scheduling desired by the client 370 - Billing-related service supported by the optical transport 371 network and/or the billing method desired by the client 372 - Vendor-related and Optional parameters 374 6. Address resolution 376 As stated in section 4.5, the source client needs to send an 377 address resolution request to obtain the ONE destination 378 termination-point ID (trusted UNI interface) or CNE termination- 380 Duroyon et al. Expires May 2001 7 381 draft-duroyon-te-ip-optical-01.txt November 2000 383 point ID (untrusted UNI interface) corresponding to the destination 384 CNE logical-address. 386 Consequently, at a trusted UNI interface, the G.LSP create message 387 sent by the CNE to the ONE includes the source and destination ONE 388 (or CNE) termination-point IDs requested for this G.LSP. This 389 implies that the source ONE must perform a internal address-lookup 390 toward a directory service or a local mapping table, in order to 391 find the mapping between the destination CNE termination-point ID 392 and the destination ONE termination-point ID. 394 So, the optical network client only needs to know the CNE source 395 and destination logical address and termination-point ID in order 396 to request a G.LSP creation; any other topological information 397 concerning the optical network termination-point identification is 398 transparent for the client. 400 This mechanism is also adapted for inter-domain G.LSP (cf. Section 401 9.1) since in this case only the autonomous-system (AS) boundary 402 ONE termination-point to CNE termination-point mapping-list has to 403 announced to the neighboring BGP AS's. 405 7. Optical Service Level Agreements 407 An optical domain-IP service domain boundary coincides with a UNI 408 with its associated O-SLA. Similarly, if there are multiple optical 409 sub-networks in the optical domain, there will be O-SLAs negotiated 410 at each optical sub-network boundary. An optical sub-network 411 boundary then corresponds to an optical Network-to-Network 412 Interface (NNI). In this draft, we limit the discussion to O-SLAs 413 at the level of UNIs. 415 As mentioned before, G.LSP requests issued by a boundary CNE are 416 only accepted within the constraints of an O-SLA. This means that 417 in case of an untrusted peering relationship, each G.LSP request is 418 authenticated and validated against the O-SLA. It was already 419 indicated that O-SLAs may also be defined at trusted interfaces. 420 However, G.LSP requests received from trusted neighbors don't need 421 to be validated against the O-SLA. 423 In the scope of this draft, we only discuss the technical aspects 424 of an O-SLA. Borrowing from the terminology introduced in 425 [diffserv-framework], we refer to the technical part of an O-SLA as 426 an Optical Service Level Specification (O-SLS). An O-SLS is 427 considered to be unidirectional and to specify performance 428 expectations (i.e., the service level) for the IP service domain as 429 well as imposed reachability constraints, e.g., CUG. 431 O-SLS parameters could for example include: 433 1. Capacity constraints 435 Duroyon et al. Expires May 2001 8 436 draft-duroyon-te-ip-optical-01.txt November 2000 438 An ingress O-SLS may contain limits on the maximum number of G.LSPs 439 that can be established from a specific ingress point, possibly as 440 a function of time of day, as well as bandwidth constraints (OC-48, 441 OC-192, etc.). 442 An egress O-SLS may put capacity constraints on the G.LSPs that the 443 receiving IP service domain is willing to terminate. 445 2. Service performance parameters 447 Examples are G.LSP setup and/or recovery admitted latency, 448 supported protection/restoration options, availability, supported 449 routing constraints, accessibility (i.e., G.LSP request blocking 450 probability), responsiveness (specifying upper limits on the 451 processing time of G.LSP requests), etc. 453 3. Constraints on the 'scope' of G.LSP request 455 This may be viewed as an extension to the concept of CUGs, which by 456 nature already exhibit reachability limitations. Scope constraints 457 are intended to additionally restrict the topological extent of 458 G.LSPs. In its simplest form, the O-SLS offers to accept any G.LSP 459 request issued by the IP service domain over a specific O-UNI up to 460 a maximum capacity without any scope constraint within the CUG (so- 461 called hose O-SLS). Conversely, the agreement may be constrained by 462 the egress point of a G.LSP. For example, the optical domain 463 service provider might agree to the setup of G.LSPs, up to a 464 certain maximum capacity, but only if these G.LSPs are destined to 465 a specific set of egress points within the CUG. 467 Part of the purpose of O-SLSs is to protect resources in the 468 optical domain by validation of submitted G.LSP requests. If the 469 optical domain and the IP service domain are under control of the 470 same administrative authority, then there is likely to be a trusted 471 peering relationship between both domains. Conversely, in case of 472 an untrusted peering relationship, the optical domain service 473 provider validates incoming G.LSP requests as per the O-SLS. This 474 validation process can be implemented in the ONE-C. In this case, 475 there exist several mechanisms to install an O-SLS in an ONE-C, 476 e.g., CLI, SNMP, LDAP or COPS. Alternatively, the O-SLS enforcement 477 may be outsourced to another policy entity. 479 An O-SLS offers to accept G.LSP requests at the service level 480 agreed with the IP service domain. The optical domain service 481 provider will provision the optical domain accordingly. A broad 482 range of optical services could be envisioned. As an example, 483 services could be defined with different levels of accessibility, 484 depending on the probability that a G.LSP establishment request is 485 blocked. Moreover, services could also be categorized as protected 486 or non-protected, depending on the offered protection level. All of 487 these service level characteristics influence the resource 488 provisioning process in the optical backbone. 490 Duroyon et al. Expires May 2001 9 491 draft-duroyon-te-ip-optical-01.txt November 2000 493 For each G.LSP request, the optical domain service provider may 494 also need to identify the O-SLS for which the request is submitted. 495 Some authentication may be included in the request in order to 496 verify that the rightful IP service provider issued the request. In 497 some cases, this customer might be implicitly derived from the 498 signaling channel on which the G.LSP request was received. The 499 authentication mechanism must be specified in the O-SLS. 501 Although it can be assumed that O-SLSs will be static for the 502 foreseeable future, this draft does not preclude dynamic O-SLSs. 503 These would necessitate some automated form of interaction between 504 the IP service domain and the optical domain. In case of an O-SLS 505 at the O-UNI, this may for instance require the interaction between 506 a Bandwidth Broker (BB) in the IP service domain and a Lambda 507 Broker (LB) in the optical domain. At the level of an O-NNI, this 508 would be between different LBs, acting on behalf of the different 509 optical sub-networks. This automated (re-)negotiation of O-SLSs 510 would in turn call for an automated O-SLS admission control 511 function. Note that this admission control function is different 512 from the validation of G.LSP requests as per the negotiated O-SLS, 513 referred to as O-SLS enforcement. 515 8. G.LSP triggers 517 As stated in [ip-optical], the G.LSP request triggering process 518 should be part of a stable traffic engineering tool in the IP 519 service domain as opposed to a data-driven shortcut approach, 520 similar to the schemes proposed for IP over ATM networks. 521 Henceforth, an integrated TE-LSP and G.LSP triggering process is 522 proposed at the end of this section to alleviate the shortcomings 523 of the former method and is elaborated below. 525 8.1 Data-driven shortcut approach for G.LSPs 527 The data-driven shortcut model would imply that the boundary CNEs 528 use traffic measurements to autonomously control the number of 529 G.LSPs that connect them with a set of remote boundary CNEs across 530 the optical domain. For example, boundary CNE A could detect that 531 some of its traffic is reaching boundary CNE B in a multi-hop way. 532 If this traffic trunk is large enough, boundary CNE A might decide 533 to set-up a G.LSP to boundary CNE B, relieving the IP forwarding at 534 all intermediate CNEs on the multi-hop path. In an overlay model, 535 once a G.LSP has been established to a new destination, it should 536 be announced as a (new) IP link in the IP service domain routing 537 database. As such, it can be used by any TE entity in the IP 538 service domain and this IP link may carry several TE-LSPs. This 539 implies that the TE entity in the IP service domain would then be 540 constantly reacting to decisions of the boundary CNEs that are 541 continuously changing the IP topology. 543 Such a layered scheme of G.LSP requests and TE-LSP requests is 544 inefficient and could also break the TE service model, when the 546 Duroyon et al. Expires May 2001 10 547 draft-duroyon-te-ip-optical-01.txt November 2000 549 only available G.LSP between two boundary CNEs would be torn down. 550 Such a decision might be based on the valid observation that the 551 traffic pattern has changed such that the existing G.LSP is under- 552 utilized and may be re-directed towards another boundary CNE. 553 However, the G.LSP might still carry TE-LSPs. Turning off the G.LSP 554 has the effect of a link failure and will hence trigger the TE 555 entity in the IP service domain to recover from this failure. 556 Depending on whether the TE-LSP was protected or not, one of the 557 following scenarios will take place. 559 8.1.1 Protected TE-LSPs 561 TE-LSPs can be used to carry mission critical traffic requiring a 562 fast recovery scheme in case of link failures. Upon such an event, 563 the traffic of the working TE-LSP can be switched to a protect TE- 564 LSP that has been pre-configured along a node- and link-disjoint 565 path. Depending on whether G.LSP is protected or not throughout the 566 optical network, the following alternative is considered: 568 - Protected G.LSP: if the turned-off G.LSP was protected within the 569 optical domain, the TE-LSP path calculation might have selected 570 this IP link for both the working and the protect path of the TE- 571 LSP. In that case, the TE-LSP protect path will not be available 572 and connectivity will be lost. 574 - Unprotected G.LSP: in this case the problem would not arise since 575 the route diversity TE-LSP protect scheme would have selected 576 another IP link for the protect path. 578 8.1.2 Unprotected TE-LSPs 580 If the TE-LSP was not protected, the source nodes of the TE-LSPs 581 running over the turned-off G.LSP will start a CSPF calculation to 582 find an alternative path. As all source nodes will be competing for 583 the same resources, some G.LSP requests will be blocked and it 584 might take a while before all G.LSPs have been restored. 586 The above scenario equally pertains to the case of any link failure 587 in an IP service domain. However, link failures in an IP service 588 domain may be considered as rare events. This is however not the 589 case when this link failure behavior is the result of a data-driven 590 shortcut approach across an optical backbone. 592 8.2 Integrated TE-LSP and G.LSP triggering process 594 Given the above shortcoming, boundary CNEs should not autonomously 595 decide to tear down a G.LSP. Yet, it may not always be appropriate 596 to maintain an under-utilized G.LSP. However, a G.LSP should not be 597 turned off until the TE-LSPs it carries, have been re-routed along 598 an alternative path. This might even require an additional G.LSP 599 setup between two other boundary CNEs. All of this calls for a 600 coordinated TE-LSP and G.LSP triggering process, integrated in the 602 Duroyon et al. Expires May 2001 11 603 draft-duroyon-te-ip-optical-01.txt November 2000 605 same decision point. This is possible since both responsibilities 606 reside within the IP service domain. 608 The ability to dynamically establish G.LSPs adds an extra dimension 609 to the TE capabilities of an IP service domain. In addition to 610 forwarding packets along non-shortest paths, it is now also 611 possible to (re-)configure the topology of the IP service domain by 612 means of adding, deleting or modifying G.LSPs across the optical 613 backbone. 615 This integrated decision point will use the set of IP SLAs and the 616 derived traffic trunk requirements across the IP service domain 617 (possibly complemented with traffic measurements) to determine the 618 optimal set of G.LSPs and TE-LSPs. 620 Several setup optimization strategies are possible depending on the 621 business model in use between the IP Service domain and the optical 622 domain, and also the assumptions taken on the pre-existing optical 623 topology. 625 The TE decision point has the complete knowledge of the IP 626 Topology, all optical end-points, including their logical, and 627 physical attributes (granularity, protection attributes, _). 629 The different strategies may be chosen among the following: 631 1- Minimize the number of G.LSPs to be lit up 633 This strategy fits in business models where the optical domain 634 doesn't belong to the service domain, and as such each 635 additional network G.LSP is an additional cost to the service 636 domain. The TE decision point optimizes the number of G.LSPs 637 to set up through the optical domain for a given IP traffic 638 pattern. 640 2- Add capacity without rearranging optical topology 642 Before triggering new G.LSPs, the TE decision point tries to 643 rearrange TE-LSPs without rearranging the underlying optical 644 topology. 646 3- Add capacity with specific explicit constraints 648 Some environment may lead to some specific constraints to be 649 taken into account during route computation. 651 One simple example is a mixed ATM / IP network. In this 652 example TE-LSP used by ATM and their underlying G.LSP must not 653 be rearranged during the computation to add optical capacity. 654 The TE decision point optimizes the number of G.LSP (and 655 subsequently TE-LSP topology) with the possibility of pinning 656 down some components (TE-LSP, G.LSP, _) 658 Duroyon et al. Expires May 2001 12 659 draft-duroyon-te-ip-optical-01.txt November 2000 661 4- Optimize IP topology without any optical constraint 663 TE decision point optimizes the IP topology without taking any 664 constraint on number of G.LSPs setup. The only constraints 665 taken are in this case coming from the end-points attributes. 667 In addition to the computation algorithm strategy, the TE decision 668 point also takes into account the sort of IP services to be 669 achieved, in order to achieve a consistent restoration between 670 protocol layers. 672 One simple way is to define a linear hierarchy between IP services. 674 1.- Layer 1 protection - Non-PSC Level Protection 676 This service only applies for IP link built between two PSC- 677 capable end-points. The G.LSP connecting both end-points is 678 totally protected. It means that it will be chosen from a pool 679 of G.LSPs with source and destination drop-side protection 680 (1+1, 1:1, Shared Protection). And in addition the G.LSP will 681 request a network-protected path via the optical network. 683 This service will be mainly seen in a traditional environment 684 where the service domain lies on a very reliable transport 685 layer, dedicated to any fast restoration mechanism. 687 2.- Diverse Layer 2 _ PSC Level Protection 689 This service also only applies for a G.LSP built between two 690 PSC-capable end-points (for instance, an IP link connection). 691 Two G.LSPs are requested to the optical cloud via the same 692 CNE-to-ONE interface, using source and destination drop-side 693 protected G.LSPs. 694 No optical or SDH/Sonet network protection are required for 695 the G.LSPs. But diverse optical paths are requested for both 696 G.LSPs. 698 This service makes sense in a network architecture where the 699 CNE is locally connected to an ONE, and so the diverse path 700 routing must start at the first ONE of the optical network. 702 3. Diverse Layer 2 - Network Level Protection 704 This service applies indifferently in a mixed PSC-capable (and 705 particularly for IP services) and non-PSC capable optical 706 environment, and not necessarily at the boundary CNE. 707 Two G.LSPs are requested from the IP service domain using two 708 diverse paths. In this case when the G.LSP request reaches the 709 optical cloud boundary, there is no specific protection 710 requirements towards the optical cloud. 712 Duroyon et al. Expires May 2001 13 713 draft-duroyon-te-ip-optical-01.txt November 2000 715 4. No G.LSP protection 717 This service applies when the restoration mechanisms don't 718 rely on pre-existing backup paths. In this case on protection 719 constraints have to be taken into account at the optical 720 layer. 722 As described in this paragraph, in order to create a consistent 723 end-to-end IP Service Model, network devices and TE decision point 724 have to synchronize each other to setup and maintain the adequate 725 and optimal set of G.LSPs and TE-LSPs. The resulting topology is 726 based on IP services requirements (Protection scheme, _) and 727 computation strategies (Business models, _). 729 This leads to needs for potential new standardization items, as 730 information exchange between routers and TE decision point (in case 731 of G.LSP setup failure, _). This will be tackle via subsequent 732 studies. 734 9. G.LSP advertisement to the IP layer 736 The decision point may thus trigger the set-up of an additional 737 G.LSP to an already connected boundary CNE. Alternatively, it may 738 trigger a rearrangement of existing G.LSPs, or the establishment of 739 a G.LSP to a boundary CNE that could previously not be reached 740 through the optical domain. It might very well be that the decision 741 point triggers a boundary CNE to drop a G.LSP if its capacity is no 742 longer needed to meet the requirements of the IP SLAs. 744 In order to make efficient use of the dynamicity of the G.LSP 745 create requests, the routing protocol parameters should be 746 dynamically configurable as well. This section outlines a proposal 747 to achieve a seamless integration of a new G.LSP within the IP 748 service domain for the overlay model by means of automatic 749 configuration. 751 As soon as a G.LSP to a particular boundary CNE has been lit up, it 752 is assumed that it is promoted to an operational IP link. In case 753 of, e.g., regular SDH/SONET framing, this is achieved by running 754 PPP protocol on the newly established G.LSP. 756 9.1 G.LSP set-up to a previously unreachable boundary CNE 758 The draft [ompls-ospf] defines the different facets of the creation 759 of an IP link in case of a peer-to-peer model and proposes to use 760 the newly established IP link as a forwarding adjacency in the IP 761 service domain. 763 The overlay model imposes different requirements on the IP layer of 764 the boundary CNEs. Indeed, once the first G.LSP is established 765 between two boundary CNEs and promoted as IP link, it is to be 766 advertised as a point-to-point link for IP routing in order to 768 Duroyon et al. Expires May 2001 14 769 draft-duroyon-te-ip-optical-01.txt November 2000 771 initiate the IP connectivity between the two boundary CNEs. And 772 subsequently it will allow IP reachability between the associated 773 IP service domains. 775 Two cases must be considered. The G.LSP is promoted to an IP link 776 connecting: 778 - two boundary CNEs of the same Autonomous System (IGP peering), 779 or, 781 - two boundary CNEs of different Autonomous Systems (eBGP peering). 783 The IGP and BGP peering cases do not require the same kind of 784 configuration and are described separately. 786 Note that in case of an IGP peer, it is necessary that the G.LSP be 787 bi-directional, because IGP protocols require a bi-directional 788 transport layer. Bi-directional G.LSP setup is further detailed 789 within [g-mpls] and [onni-framework]. 791 From an addressing point of view, the Packet switch capable end- 792 points can be unnumbered (and, e.g., identified by the Router Id of 793 the boundary CNE), or numbered through initial configuration, but 794 different from the IP address assigned to the UNI signaling agents 795 (UNI-Client and UNI-Network) terminating the signaling channel. 797 It has to be noticed again that within the overlay model, the 798 signaling channel identification is neither known nor advertised 799 throughout the IP service domain. 801 9.1.1 IGP support 803 Once the first IP link is established between two boundary CNEs and 804 configured to support an IGP peer, the boundary CNEs need to get 805 the proper information: 807 - The first requirement is to select IS-IS or OSPF for the newly 808 formed IP link. 810 - In addition, link routing parameters such as timers and area 811 numbers might have to be specified. For instance, timers in OSPF 812 should be consistent at both ends of the IP link. 814 - Also, link metrics (e.g., resource classes, etc.) need to be 815 inherited or configured for use by IP routing. 817 - Finally, the IGP protocol is enabled and the IP link is 818 advertised. 820 These parameters have to be accessible and are automatically 821 configured (prior to or at the time of G.LSP establishment) by the 823 Duroyon et al. Expires May 2001 15 824 draft-duroyon-te-ip-optical-01.txt November 2000 826 decision point of the IP service domain to efficiently deploy the 827 IP service on top of the G.LSP. 829 However, some of the routing parameters (e.g., OSPF timers) may be 830 defaulted to pre-determined values. Those values must be defined 831 network-wide and be consistent between all possible boundary CNE 832 pairs. The decision point should be allowed to overwrite those 833 parameters at the setup time of the G.LSP. 835 9.1.2 eBGP peering 837 In the case of an inter-domain G.LSP, static route configuration 838 specifying the BGP peer (most probably a virtual interface of the 839 remote boundary CNE) should be configured in the local boundary CNE 840 in order to set up the TCP session used in BGP. 842 In addition, an IP SLA is going to be negotiated between the 843 autonomous systems and routing policies are going to be configured 844 on both ends of the G.LSPs. 846 As opposed to the IGP peering case, triggering of inter-domain 847 G.LSPs will very likely not arise from an automated process because 848 of the BGP peering negotiation procedure. 850 9.2 Set-up of an additional G.LSP 852 In addition to the option described in 9.1 (creation of a new 853 stand-alone IP link with the new G.LSP and advertisement to the 854 routing protocol), a second option is now possible, which is to 855 create an additional G.LSP to an existing IP link that forms a 856 bundled link [mpls-bundle]. In this case there is no new 857 configuration necessary for the IGP or BGP routing layer but only 858 interactions internal to the boundary CNEs. 860 This bundle is advertised as a single IP link. The G.LSP in itself 861 may be unidirectional, and hence the bundle could have an 862 asymmetric bandwidth. 864 - The boundary CNE upgrades the bandwidth of the bundle link based 865 on the characteristics of this new G.LSP. 867 - The new G.LSP is included in the load balancing mechanism that 868 distributes the traffic amongst the component G.LSPs of the bundled 869 link, e.g., proportional to their bandwidth. 871 - The addition of a new G.LSP to a bundle does not impact the 872 routing topology. Only the new bandwidth of the IP link is 873 advertised within the IP service domain. The other characteristics 874 of the IP link, e.g., the resource classes, remain unchanged. 876 Duroyon et al. Expires May 2001 16 877 draft-duroyon-te-ip-optical-01.txt November 2000 879 In the case described in this section, the only mandatory 880 information to be automatically configured by the decision point is 881 the bundle identifier to which the G.LSP is to be added. 883 9.3 Rearrangement of an existing G.LSP 885 Within the optical network, two alternatives could be considered 886 for the rearrangement of an existing G.LSP: 887 - Either the non-destructive modification of an already established 888 G.LSP. In this case, the source and destination termination-points 889 of the G.LSP can not be changed, but other parameters such as 890 bandwidth and network protection could be modified without 891 disrupting the working G.LSP. 892 - Or the destructive modification of an already established G.LSP. 893 This case is the straightforward combination of G.LSP tear-down 894 followed by a new G.LSP set-up towards a different destination. 896 10. References 898 [diffserv-framework] Y.Bernet et al, "A Framework for 899 Differentiated Services", Internet Draft, draft-ietf-diffserv- 900 framework-03.txt, February 1999. 902 [g-mpls] Peter Ashwood-Smith et al., "Generalized MPLS _ Signaling 903 Functional Description", Internet draft, draft-ietf-mpls- 904 generalized-signaling-00.txt, October 2000. 906 [ip-optical] James Luciani et al., " IP over Optical Networks _ A 907 Framework", Internet draft, draft-ip-optical-framework-00.txt, 908 February 2000. 910 [ompls-isis] K. Kompella et al., "IS-IS Extensions in Support of 911 MPL(ambda)S", Internet Draft, draft-kompella-isis-ompls-extensions- 912 00.txt, July 2000. 914 [ompls-ospf] K. Kompella et al., "OSPF Extensions in Support of 915 MPL(ambda)S", Internet Draft, draft-kompella-ospf-ompls-extensions- 916 00.txt, July 2000. 918 [mpls-bundle] K. Kompella et al., "Link Bundling in MPLS Traffic 919 Engineering", Internet Draft, draft-kompella-mpls-bundle-02.txt, 920 July 2000. 922 [onni-framework] D.Papadimitriou et al,. "Optical NNI Framework and 923 Signaling Requirements", Work in progress, draft-papadimitriou- 924 onni-framework-00.txt, November 2000. 926 [ouni-framework] B.Rajagopalan et al., `Signaling Requirements at 927 the Optical UNI', Internet Draft, draft-bala-mpls-optical-uni- 928 signaling-00.txt, July 2000. 930 Duroyon et al. Expires May 2001 17 931 draft-duroyon-te-ip-optical-01.txt November 2000 933 [OIF2000.125.2] B. Rajagopalan et al., "User Network Interface 934 v1.0 Proposal", OIF Contribution 125.2, October 2000. 936 [OIF2000.200] D. Pendarakis et al., "Signaling Transport 937 Mechanisms for UNI 1.0", OIF Contribution 200, September 2000. 939 [OIF2000.261.1] D. Papadimitriou et al., "Address Registration and 940 Resolution", OIF Contribution 261, November 2000. 942 11. Acknowledgments 944 The authors would like to thank Emmanuel Desmet, Sitaram 945 Kalipatnapu and Gert Grammel for their constructive comments. 947 12. Author's Addresses 949 Olivier Duroyon 950 Alcatel USA 951 15036 Conference Center Drive 952 Chantilly, VA, 20151 953 Phone: (703) 679 6415 954 Email: olivier.d.duroyon@usa.alcatel.com 956 Rudy Hoebeke 957 Alcatel Bell 958 Francis Wellesplein 1 959 2018 Antwerp, Belgium 960 Phone: (32) 3/240.84.39 961 Email: rudy.hoebeke@alcatel.be 963 Hans De Neve 964 Alcatel Bell 965 Francis Wellesplein 1 966 2018 Antwerp, Belgium 967 Phone: (32) 3/240.76.94 968 Email: hans.de_neve@alcatel.be 970 Dimitri Papadimitriou 971 Alcatel NSG-NA 972 Francis Wellesplein 1 973 2018 Antwerp, Belgium 974 Phone: (32) 3/240.84.91 975 Email: dimitri.papadimitriou@alcatel.be 977 Duroyon et al. Expires May 2001 18