idnits 2.17.1 draft-papadimitriou-onni-frame-01.txt: 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (November 2000) is 8563 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) == Missing Reference: 'ITU-T' is mentioned on line 246, but not defined == Missing Reference: 'G.MPLS' is mentioned on line 1443, but not defined -- Looks like a reference, but probably isn't: '0' on line 2289 -- Looks like a reference, but probably isn't: '1' on line 2290 -- Looks like a reference, but probably isn't: '2' on line 2290 == Missing Reference: 'N-1' is mentioned on line 2290, but not defined == Missing Reference: 'N' is mentioned on line 2291, but not defined -- Looks like a reference, but probably isn't: '3' on line 2270 == Missing Reference: 'N-2' is mentioned on line 2209, but not defined == Unused Reference: 'GMPLS' is defined on line 2597, but no explicit reference was found in the text == Unused Reference: 'MPLS-LMP' is defined on line 2601, but no explicit reference was found in the text == Unused Reference: 'MPLS-TE' is defined on line 2608, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'CRLDP-OPT' == Outdated reference: A later version (-04) exists of draft-papadimitriou-enhanced-lsps-01 -- Possible downref: Normative reference to a draft: ref. 'ENH-LSPS' == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-00 == Outdated reference: A later version (-02) exists of draft-lang-mpls-lmp-01 -- Possible downref: Normative reference to a draft: ref. 'MPLS-LMP' == Outdated reference: A later version (-01) exists of draft-bala-mpls-optical-uni-signaling-00 -- Possible downref: Normative reference to a draft: ref. 'MPLS-OUNI' == Outdated reference: A later version (-02) exists of draft-venkatachalam-interarea-mpls-te-01 -- Possible downref: Normative reference to a draft: ref. 'MPLS-TE' Summary: 6 errors (**), 0 flaws (~~), 16 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D.Papadimitriou 3 Internet Draft M.Fontana 4 Document: draft-papadimitriou-onni-frame-01.txt G.Grammel 5 Expiration Date: May 2001 Alcatel 7 Yanguang Xu 8 Zhi-Wei Lin 9 S.Sankaranarayanan 10 Lucent 12 Raj Jain 13 Nayna Networks 15 Yang Cao 16 Sycamore 18 Yong Xue 19 UUNet 21 November 2000 23 Optical Network-to-Network Interface 24 Framework and Signaling Requirements 26 Status of this Memo 28 This document is an Internet-Draft and is in full conformance with 29 all provisions of Section 10 of RFC2026. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. Internet-Drafts are draft documents valid for a maximum of 35 six months and may be updated, replaced, or obsoleted by other 36 documents at any time. It is inappropriate to use Internet- Drafts 37 as reference material or to cite them other than as "work in 38 progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Abstract 46 This draft specifies the optical Network-to-Network Interface (NNI) 47 requirements for non-packet-switch capable transport networks. This 48 proposal defines for such networks the NNI signaling and routing 49 requirements as well as the corresponding mechanisms and procedures. 51 Papadimitriou et al. Expires May 2001 1 52 The main objective is to propose a common approach for most of the 53 models currently available for non-packet-switch optical transport 54 networks. The signaling paradigm implicitly referenced within this 55 document is the one defined by the G.MPLS concept. However, in a 56 first approach, this proposal is not focused on a specific and 57 detailed implementation of the G.MPLS signaling protocol. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC-2119. 65 Table of Contents 67 1. Introduction..................................................3 68 2. Terminology...................................................4 69 3. NNI Reference Model...........................................5 70 3.1 Client-to-Network Boundary and Network-to-network model...5 71 3.2 Network-to-network model..................................6 72 3.2.1 Network-to-network - Model Overview ................6 73 3.2.2 Network-to-network - Reference Models...............9 74 4. Signaling transport mechanisms at the NNI.....................10 75 4.1 NNI Signaling Requirements................................10 76 4.2 NNI Signaling Transport Mechanisms........................11 77 4.3 Availability of Signaling Network.........................12 78 4.4 Security of the Signaling Network.........................12 79 5. Neighbor discovery protocol...................................13 80 5.1 Neighbor discovery related concepts.......................13 81 5.2 Neighbor identity discovery...............................14 82 5.2.1 Basic identification-related discovery..............14 83 5.2.2 Additional Identification-related discovery.........14 84 6. NNI Topology and Resource Distribution Protocol...............15 85 6.1 Transport Mechanism.......................................16 86 6.2 Protocol Requirements.....................................16 87 6.3 TrDP Discovery Protocol...................................17 88 6.3.1 Logical-port Resource discovery.....................17 89 6.3.2 Logical-port Address discovery......................18 90 6.3.3 Logical-port Service discovery......................19 91 6.4 TrDP Protocol Mechanisms..................................21 92 6.4.1 ONE Advertisements and Flooding Process.............21 93 6.4.2 Topology and Local ONE Database.....................22 94 6.4.3 Flooding rules......................................24 95 6.4.4 ONE Advertisement types.............................26 96 6.4.5 Additional mechanisms...............................26 97 7. NNI Signaling Mechanisms and Protocol.........................27 98 7.1 UNI G.LSP Signaling Services..............................27 99 7.2 NNI Signaling Requirements................................27 100 7.3 NNI Signaling Paradigm and Protocols......................28 101 7.4 NNI Signaling Interfaces..................................28 102 7.5 NNI Signaling Messages....................................30 104 Papadimitriou et al. Expires May 2001 2 105 7.5.1 G.LSP Creation......................................30 106 7.5.2 G.LSP Deletion......................................33 107 7.5.3 G.LSP Modification..................................35 108 7.5.4 G.LSP Status........................................38 109 7.5.5 Notifications.......................................39 110 7.6 Constraint-based Routing..................................39 111 7.6.1 Bi-directional G.LSP setup..........................39 112 7.6.2 Explicit route......................................40 113 7.6.3 Record route........................................43 114 7.7 Extended NNI Signaling Services...........................44 115 7.7.1 Framing-Bandwidth _ Priority........................45 116 7.7.2 Protection _ Priority...............................46 117 7.7.3 Preemption..........................................46 118 8. Hierarchical Network Model....................................47 120 1. Introduction 122 The framework presented in this proposal combines the Domain Service 123 Model between the client and the optical network whose architecture 124 is based on a centralized or a distributed model. Within this model, 125 the signaling and routing interface between the client and the 126 optical network is referred as the User-to-Network Interface (UNI); 127 and the signaling and routing interface between element belonging to 128 the optical network as the Network-to-Network Interface (NNI). 130 This is the only postulate included within this proposal except that 131 we do not consider in a first approach packet-switch capable devices 132 within the optical network. 134 Many models have been developed for the client network inter- 135 connection: peer, overlay and augmented models are the most 136 familiar; this is also the case concerning the routing model: 137 integrated, overlay and domain specific. Since we consider a 138 boundary interface between the client network and the optical 139 network, combination of the peer model and integrated routing are 140 precluded at the UNI. 142 Since, there is no direct relationship between the model and the 143 signaling, more precisely the signaling paradigm and signaling 144 transport protocol, this proposal covers any kind of optical network 145 model using any kind of signaling paradigm and protocol. 147 The remainder of the document is organized as follows: 149 Section 3 presents the network-to-network models by detailing the 150 specific features of the distributed and centralized models. Section 151 4 describes the requirements and mechanisms of the NNI signaling 152 transport. The section 5 is dedicated to the Neighbor Discovery 153 Protocol (NDP), which is closely related to the Topology and 154 resource Distribution Protocol (TrDP) explained in section 6. This 155 section includes the TrDP protocol requirements, mechanisms and 157 Papadimitriou et al. Expires May 2001 3 158 related discovery processes. The section 7 is entirely dedicated to 159 the NNI signaling. In this section, the NNI signaling requirements, 160 protocols and abstract messages are detailed. Finally, section 8 161 presents the hierarchical optical network model. 163 2. Terminology 165 The following terms are used in this document. These definitions 166 take into account the terminology already defined by the IETF for 167 some of the concepts defined here and some are adapted from the OIF 168 Forum terminology. 170 - Optical Network: a collection of optical sub-networks constituted 171 by optical network elements. 173 - Optical Network Element (ONE): a network element belonging to the 174 optical network. An optical network device could be an Optical 175 Cross-Connect (OXC), Optical ADM (OADM), etc. 177 - ONE controller: the owner of the UNI-N interface (since the UNI-N 178 may not belong to the same device as the ONE) toward the UNI-C 179 interface and/or the owner of the NNI interface. 181 - Boundary ONE: an optical network element belonging to the optical 182 network whose controller includes an IrDI-NNI interface and an IaDI- 183 NNI interface and/or an UNI-N interface. 185 - Internal ONE: an optical network element internal to the optical 186 network (also referred as a termination incapable device) whose 187 controller has only IaDI-NNI interface. 189 - Client Network Element (CNE): a network element belonging to the 190 client network. A client network element could be a SONET/SDH ADM, a 191 SONET/SDH Cross-connect, an ATM Switch, an Ethernet switch, an IP 192 router, etc. 194 - CNE controller: the owner of the UNI-C interface (since the UNI-C 195 may not belong to the same device as the boundary CNE) 197 - Optical Network Controller (ONC): logical entity within an optical 198 sub-network terminating the NNI signaling. 200 - Intra-Domain (IaDI)-NNI Interface: the interface between Internal 201 ONE controllers belonging to the same optical sub-network or between 202 Internal ONE controllers belonging to distinct optical sub-networks. 204 - Inter-Domain (IrDI)-NNI Interface: the interface between Boundary 205 ONE controllers belonging to distinct optical networks. 207 - Generalized Label Switched Path (G.LSP): point-to-point connection 208 with specified attributes (mandatory and optional) established 209 between two termination points in the optical network. G.LSPs are 211 Papadimitriou et al. Expires May 2001 4 212 considered as bi-directional (and in a first phase as symmetric). A 213 G.LSP could be a Fiber Switched path, Lambda Switched path or TDM 214 Switched path (Circuit). 215 However, within the scope of the first version of this draft, we 216 restrict the network to a non-packet switch capable network and the 217 G.LSPs to non-packet switch capable LSPs. 219 - G.LSP termination-point: an addressable termination-point in the 220 optical network between which a G.LSP is established through the UNI 221 signaling. 223 - UNI Client (UNI-C): signaling and routing interface between a 224 Boundary CNE controller and an ONE controller belonging to an 225 optical network. 227 - UNI Network (UNI-N): signaling and routing interface between a 228 Boundary ONE controller and a CNE controller belonging to a client 229 network. 231 - UNI Services: the services defined at the UNI are the following: 232 - Neighbor discovery service 233 - Service discovery service 234 - G.LSP signaling services (create/delete/modify/status) 236 - NNI Protocols: the protocols defined at the NNI are the following: 237 - Neighbor discovery protocol 238 - Topology and resource Distribution Protocol (OSPF based 239 protocol 240 - Traffic engineering (CSPF based) 241 - G.LSP signaling protocol (CR-LDP based or RSVP-TE protocol) 243 - NMI interface: the interface between the ONE controller and the 244 centralized management server. 246 Concerning the relationship with this terminology and others [ITU-T] 247 we consider within this document that the term Client is equivalent 248 to User, Optical network to Service provider network, Controller to 249 Signaling agent, Trusted to Private and Untrusted to Public. 251 3. NNI Reference Model 253 This section introduces the NNI reference model by first recalling 254 some basic aspects concerning the UNI reference model. 256 3.1 Client-to-Network Model 258 The network-to-network model is related to the client-to-network 259 model. For the sake of this proposal, we first briefly describe the 260 client-to-network model. For more details concerning the 261 corresponding reference model refer to [MPLS-OUNI]. 263 Papadimitriou et al. Expires May 2001 5 264 +------------+ 265 -----| MGT Server |----- 266 | +------------+ | 267 | | 268 | NMI | NMI 269 +----------------+ +----------------+ +----------------+ 270 |+--------------+| |+--------------+| |+--------------+| 271 || Boundary CNE || || Boundary ONE || || Internal ONE || 272 || Controller || UNI || Controller || IaDI || Controller || 273 || || || || -NNI || || 274 || UNI-C||_._._||UNI-N IaDI-NNI||_._._.||IaDI-NNI || 275 |+--------------+| |+--------------+| |+--------------+| 276 | | | | | | | | | 277 | | | | | | | | | 278 |+--------------+| |+--------------+| |+--------------+| 279 || ||-----|| || || || 280 || Boundary CNE ||-----|| Boundary ONE ||======|| Internal ONE || 281 || ||-----|| || || || 282 |+--------------+| |+--------------+| |+--------------+| 283 +----------------+ +----------------+ +----------------+ 285 Figure 1: Client-to-Network Boundary and Network-to-Network Model 287 UNI signaling communication takes place between UNI-Client (UNI-C) 288 and UNI-Network (UNI-N) as referenced by the OIF document through 289 the UNI signaling channel. Thus the server implements the UNI-N 290 interface and the client the UNI-C interface. Details concerning the 291 signaling transport mechanism are detailed in the OIF Contribution 292 [OIF2000.200]. 294 Details concerning the UNI Reference models are detailed in the OIF 295 Contribution [OIF2000.125.2], User Network Interface v1.0 Proposal 296 and in the IETF Informational Draft [MPLS-OUNI]. 298 3.2 Network-to-network Model 300 The network-to-network reference models include the centralized and 301 distributed approaches of the optical intra- and inter-networking 302 concept. 304 3.2.1 Network-to-network: Model Overview 306 The distributed approach of network-to-network model is represented 307 by the following figure: 309 Papadimitriou et al. Expires May 2001 6 310 +-------------+ 311 |Internal ONE1| IaDI-NNI 312 |Optical SubN1|------ 313 +-------------+ | +-------------+ IrDI-NNI +-------------+ 314 ------|Boundary ONE3|----------|Boundary ONE8| 315 +-------------+ ------|Optical SubN1|----------|Optical SubN3| 316 |Internal ONE2| | +-------------+ +-------------+ 317 |Optical SubN1|------ | | | | 318 +-------------+ IaDI-NNI | | | | 319 |IrDI-NNI | | |IrDI 320 | | | |-NNI 321 | | | | 322 | | | | 323 +-------------+ IaDI-NNI +-------------+ IrDI-NNI +-------------+ 324 |Internal ONE4|-------------|Boundary ONE5|----------|Boundary ONE9| 325 |Optical SubN2|-------------|Optical SubN2|----------|Optical SubN4| 326 +-------------+ +-------------+ +-------------+ 327 | | | | | 328 | | |IaDI-NNI | |IaDI-NNI 329 | | | | | 330 +-------------+ IaDI-NNI +-------------+ 331 |Internal ONE6|-------------|Internal ONE7| 332 |Optical SubN2|-------------|Optical SubN2| 333 +-------------+ +-------------+ 335 Figure 2: Network-to-network: Distributed Model Overview 337 Within this figure, we have 4 optical sub-networks, 4 boundary ONEs 338 and 5 internal ONEs: 339 - Optical sub-network1 includes 2 internal ONEs and 1 boundary ONE 340 - Optical sub-network2 includes 3 internal ONEs and 1 boundary ONE 341 - Optical sub-network3 includes 1 boundary ONE 342 - Optical sub-network4 includes 1 boundary ONE 344 The same optical network can be represented in the centralized 345 approach for the optical sub-network1 (others are not represented 346 for clarity of the figure): 348 Papadimitriou et al. Expires May 2001 7 349 +---------+ 350 ===================| ONC |=== 351 | ========|NNI Agent| | 352 | | +---------+ | 353 | | | 354 | +-------------+ | 355 | |Internal ONE1| | 356 | |Optical SubN1|---- | 357 | +-------------+ | +-------------+IrDI-NNI+-------------+ 358 | -----|Boundary ONE3|--------|Boundary ONE8| 359 | +-------------+ -----|Optical SubN1|--------|Optical SubN3| 360 | |Internal ONE2| | +-------------+ +-------------+ 361 ===|Optical SubN1|-- | | | | 362 +-------------+ | | | | 363 |IrDI-NNI IrDI-NNI| | | 364 | | | | 365 | | | | 366 +-------------+IaDI-NNI+-------------+IrDI-NNI+-------------+ 367 |Internal ONE4|--------|Boundary ONE5|--------|Boundary ONE9| 368 |Optical SubN2|--------|Optical SubN2|--------|Optical SubN4| 369 +-------------+ +-------------+ +-------------+ 370 | | | | | 371 | | |IaDI-NNI | |IaDI-NNI 372 | | | | | 373 +-------------+IaDI-NNI+-------------+ 374 |Internal ONE6|--------|Boundary ONE7| 375 |Optical SubN2|--------|Optical SubN2| 376 +-------------+ +-------------+ 378 Figure 3: Network-to-network: Centralized Model Overview 380 The Optical Network Controller (ONC) includes an NNI agent which 381 implements the inter-domain NNI interface functions and terminates 382 the inter-domain NNI signaling. The ONC may also implement the 383 intra-domain NNI interface functions and terminate the intra-domain 384 NNI signaling. 386 This proposition considers the inter-optical sub-networks 387 communication. In this case, as indicated in the above figures, 388 there is a clear distinction between NNI interfaces: 389 - an IaDI-NNI interface for the intra-domain NNI interface 390 - an IrDI-NNI interface for the inter-domain NNI interface 392 To distinguish between trusted and untrusted peers, we propose a 393 separate definition between a Trusted NNI interface and a Untrusted 394 NNI interface: 395 - Untrusted interface is defined as an NNI interface between two 396 ONEs belonging to distinct administrative authorities (untrusted NNI 397 relationship). 399 Papadimitriou et al. Expires May 2001 8 400 - Trusted interface is defined as an NNI interface between two ONEs 401 belonging to the same administrative authority defines a (trusted 402 NNI relationship). 404 So, for instance, in figure 2, ONE1 is connected to ONE3 and they 405 belong to the same administrative authority; hence, the NNI 406 interface between these devices is considered as a trusted NNI 407 interface. 409 In the same figure, the ONE3 is also connected to ONE8 but they do 410 not belong to the same administrative authority; hence the NNI 411 interface between these devices is considered as an untrusted NNI 412 interface. 414 Under the model specified here above, the optical network control 415 plane is based on the following components: 416 - boundary ONE controllers 417 - and internal ONE controllers 418 or the following logical interfaces: 419 - IaDI-NNI interfaces 420 - and IrDI-NNI interfaces 422 It has to be noticed that a boundary ONE Controller can have both 423 IaDI-NNI interface and IrDI-NNI interface. 425 The control interface between the ONE-Controller and the ONE (even 426 if this interface does not concern the NNI specifications) is 427 dedicated to the communication between the ONE and the ONE- 428 Controller. So, this proposal considers to optionally make a 429 distinction between internal and external control interface: 430 - an Internal Control Interface (ICI) refers to an ONE and an ONE-C 431 located in the same element 432 - an External Control Interface (ECI) refers to an ONE and an ONE-C 433 located in separated elements. 435 3.2.2 Network-to-network - Reference Models 437 Reference models are based on the centralized (1) and distributed 438 models (2) and the following concepts: 439 - within an optical sub-network, NNI interfaces are defined as 440 Trusted IaDI-NNI interfaces 441 - between optical sub-networks, NNI interfaces are defined as either 442 Trusted IaDI-NNI interfaces or Trusted IrDI-NNI interfaces 443 - between optical networks, NNI interfaces are defined as Untrusted 444 IrDI-NNI interfaces 446 1. Centralized model 448 Within an optical sub-network, all ONE controllers are concentrated 449 on a single instance, the Optical Network Controller meaning there 450 is no IaDI-NNI signaling between ONEs belonging to the same optical 451 sub-network. 453 Papadimitriou et al. Expires May 2001 9 454 Between optical sub-networks, Trusted NNI signaling starts at the 455 ONC but can end either at the ONC of the neighboring sub-network or 456 the NNI interface of a neighboring ONE. In the first case, we have a 457 centralized-to-centralized NNI signaling and in the second case a 458 centralized-to-distributed NNI signaling. 460 The same concept applies between optical networks, Untrusted NNI 461 signaling starts at the IrDI-NNI interface of the ONC controller but 462 can end either at the ONC of the neighboring optical network or the 463 Untrusted NNI interface of a neighboring ONE. 465 2. Distributed model 467 Within an optical sub-network, all ONE controllers are distributed 468 and ONE-to-ONE controller communication is performed through the 469 IaDI-NNI interface of each the ONE controllers. There is at least 470 one IaDI-NNI signaling channel between each ONE controller. 472 Between optical sub-networks, Trusted NNI signaling starts at the 473 NNI interface of the ONE controller and ends either at the ONC of 474 the neighboring sub-network or at the NNI interface of a neighboring 475 ONE. In the first case, we have a distributed-to-centralized NNI 476 signaling and the second a distributed-to-distributed NNI signaling. 478 The same concept applies between optical networks, Untrusted NNI 479 signaling starts at the IrDI-NNI interface of ONE controller but can 480 end either at the ONC of the neighboring optical network or the 481 Untrusted NNI interface of a neighboring ONE. 483 4. Signaling transport mechanisms at the NNI 485 This section details the NNI signaling requirements and the NNI 486 signaling transport mechanisms; the availability and security of the 487 signaling network are also considered here. 489 Moreover, this section does not make any distinction between the 490 intra- and inter-domain NNI interfaces within the scope of the 491 considered models since the corresponding transport mechanisms do 492 not depend on the NNI interface function. Additionally, and for the 493 same reason, there is no distinction between untrusted and trusted 494 NNI interfaces within this section. 496 Concerning the signaling transport mechanism, the centralized model 497 is a particular case to be considered since the NNI signaling starts 498 at the local ONC and ends at the neighboring ONC controller. 500 4.1 NNI Signaling Requirements 502 Before specifying the signaling transport mechanism at the NNI, we 503 first describe the signaling requirements for both in-band and out- 504 of-band NNI control-channels: 506 Papadimitriou et al. Expires May 2001 10 507 - Between the NNI interfaces, the signaling protocol could be IP- 508 based; the NNI interface IPv4 address is the one uniquely associated 509 to the ONE controller. 510 - Knowledge of the NNI IPv4 address could be static or dynamic, 511 i.e., the NNI discovers the NNI IPv4 address of its neighboring ONEs 512 through the Neighbor Discovery Protocol. 513 - When an ONE is connected through multiple interfaces to a 514 neighboring ONE (i.e., there are multiple transport links between 515 these ONEs), only one NNI control-channel must be logically defined 516 between these ONEs. 517 - Availability of the NNI control-channel mechanism could be based 518 on PPP Multi-link protocol. In a first phase, we do not consider the 519 use of the Link Management Protocol for this functionality as 520 proposed by the [MPLS_LMP]. 522 In case of an out-of-network signaling mechanism, the signaling 523 requirements are the same but apply between ONC controllers: 524 - Between the NNI interfaces, the signaling protocol could be IP- 525 based, the NNI interface IPv4 address is the one uniquely associated 526 to the NNI signaling agent of the ONE/ONC Controller. 527 - Knowledge of the NNI IPv4 address could be static or dynamic, 528 i.e., the NNI discovers the NNI IPv4 address of its neighboring ONE/ 529 ONC Controller NNI signaling agent. The corresponding discovery 530 protocol requires further investigation. 531 - When the ONC is connected through multiple interfaces to a 532 neighboring ONE/ONC Controller, only one NNI control-channel must be 533 logically defined between these entities. 534 - Availability of the NNI control-channel mechanism could be based 535 on PPP Multi-link protocol or other protection mechanisms (TBD). 537 To ensure the inter-operability between both in-band and out-of-band 538 and out-of-network signaling mechanisms, the boundary ONE must act 539 as a signaling relay entity. If the NNI control-channel is defined 540 between an sub-network boundary ONE NNI interface and an ONC which 541 implements the NNI functionality, then this boundary ONE must act as 542 a relay entity for the signaling protocol. 544 4.2 NNI Signaling Transport Mechanisms 546 In this proposal, the following signaling transport mechanisms are 547 considered; for each of these signaling mechanisms, a specific 548 transport mechanism has been defined: 550 - In-band: signaling messages are carried over a control-channel 551 embedded in the logical link between the NNI interfaces of the 552 peering ONE controllers. The control-channel is implemented through 553 the use of Optical Channel layer (OCh) overhead bytes [ITU-T G.709 554 v0.83] over which the NNI signaling channel is realized. For the 555 SDH/Sonet particular case, the control-channel could be implemented 556 through line DCC bytes or other SDH/Sonet unused overhead bytes. 558 Papadimitriou et al. Expires May 2001 11 559 - Out-of-band: signaling messages are carried over a control-channel 560 embedded in the physical link between the NNI interfaces of the 561 peering ONE controllers. The control-channel is implemented through 562 the use of a dedicated wavelength included on a (D)WDM fiber link 563 over which the NNI signaling channel is realized. This channel is 564 referenced as the Optical Supervisory Channel (OSC). For the 565 SDH/Sonet particular case, a TDM sub-channel can be allocated for 566 realizing the NNI signaling channel. 568 - Out-of-network: signaling messages are carried over a dedicated 569 and separated network between NNI Agent interfaces of the peering 570 ONC controllers or over a dedicated control-link between NNI 571 interfaces of the peering ONE controllers. The dedicated physical- 572 link is implemented through the use of one (or multiple) dedicated 573 interface(s) over which the NNI signaling channel is realized. 575 The framing used on top of the signaling control-channel could be 576 the PPP protocol in HDLC-like framing [RFC 1662] or PPP protocol 577 over SDH/Sonet [RFC 2615]. In case where the ONE (respectively ONC) 578 is connected through multiple link to a neighboring ONE 579 (respectively ONC), PPP Multilink could be the protocol used to 580 carry the signaling messages over the control-channels between the 581 NNI interfaces. The availability of the signaling transport 582 mechanism is described in the next sub-section. 584 4.3 Availability of the Signaling Network 586 We assume here that the signaling control-plane network is either 587 explicitly configured or automatically discovered and selected 588 through the following rules: first select the in-band signaling 589 network, then select the out-of-band signaling network otherwise 590 select the out-of-network signaling network. 592 These rules depend on the signaling transport mechanism supported by 593 the ONE. If a specific signaling transport mechanism is required by 594 one (or both) of the neighboring ONEs, the signaling transport 595 mechanism can be explicitly specified by the requestor. The explicit 596 configuration can also include the backup signaling transport 597 mechanism. 599 4.4 Security of the Signaling Network 601 In order to increase the security level of the signaling between 602 ONEs (respectively ONC), the use of a bi-directional Challenge 603 Handshake Authentication Protocol (CHAP) is considered. Bi- 604 directional (or symmetric) CHAP exchange between ONE controllers 605 (respectively ONCs) is provided for the authentication of both peers 606 constituting the end-points of the signaling control-channel. 608 Other authentication protocols such as IPSEC Authentication Header 609 or IPSEC Encrypted Payload mechanism could also be defined for the 610 IP based signaling between Untrusted NNI interface. 612 Papadimitriou et al. Expires May 2001 12 613 5. Neighbor Discovery Protocol 615 The key objective of the Neighbor Discovery Protocol (NDP) at the 616 NNI is to provide the information needed to determine the neighbor 617 identity (IPv4 address associated to the corresponding NNI) and 618 neighbor connectivity over each link connecting internal ONEs or an 619 internal ONE to a boundary ONE. 621 The Neighbor Discovery Protocol is fundamentally an in-fiber 622 mechanism. Within an in-fiber signaling transport mechanism, 623 signaling messages are carried over a control-channel embedded 624 either in the logical link or in the physical link between the NNI 625 interfaces of the peering ONE. Consequently, the neighbor discovery 626 protocol does not apply to centralized optical sub-network 627 topologies. 629 5.1 Neighbor Discovery Protocol: Related concepts 631 We first define the concepts considered in this and subsequent 632 sections to describe the neighbor discovery protocol. To each of 633 these concepts, an identifier is associate to enable the inter- 634 operability: 635 - A logical-port defines the logical structure of a physical port by 636 identifying for a given port each of the channels included within 637 this port and sub-channel included within this channel. 638 - A logical-port ID identifies a logical-port. The logical-port ID 639 is defined as the concatenation of the port-ID, channel-ID and the 640 sub-channel ID. 641 - An internal-point ID is defined as the concatenation of the 642 logical-port ID and the IP address of the ONE to which this logical- 643 port belongs. 645 A logical-port can also be defined by using the G.MPLS terminology 646 [G.MPLS] as follows: 647 - a Time-Division Multiplex Capable interface 648 - a Lambda Switch Capable interface 649 - or a Fiber-Switch Capable interface 651 So, in a first approach, this document does not consider an optical 652 logical-port as a Packet-Switch Capable (PSC) interface since such 653 optical interfaces do not recognize packet boundaries and are 654 incapable of forwarding data based on the content of packet header. 655 Hence, in the remaining sections of this document, an internal-point 656 ID never identifies a PSC interface. Introduction of PSC interfaces 657 is for further study. 659 Consequently, by taking into account the proposed definitions, we 660 have the following mapping between these definitions: 661 - a logical-port identified by the port ID refers to Fiber-Switch 662 Capable interface 664 Papadimitriou et al. Expires May 2001 13 665 - a logical-port identified by the port ID and the channel ID refers 666 to a Lambda Switch Capable interface 667 - a logical-port identified by the port ID, channel ID and sub- 668 channel ID refers to a Time-Division Multiplex Capable interface 670 If we extend these definitions to the client addressable logical- 671 ports then a logical-port identified by a logical-address refers to 672 a PSC interface. 674 5.2 Neighbor identity discovery 676 The neighbor identity discovery is considered here for in-band and 677 out-of-band signaling transport mechanism. 679 5.2.1 Basic identification-related discovery 681 The physical port and identity discovery provides the following 682 information to the ONE: 683 - the ONE discovers the identity of the neighboring ONE by 684 automatically discovering the IPv4 address assigned to the NNI 685 interface 686 - the ONE discovers the identity of the physical ports of each port 687 connected to the neighboring ONE 689 The knowledge of the IP address is the key to establish the NNI 690 signaling control-channel between two neighboring ONEs. 692 For the in-band, the proposed transport mechanism is based on the 693 overhead bytes of the Optical Channel Sub-Layers (OPU Overhead bytes 694 _ ODU Overhead bytes _ OTU Overhead bytes) as defined by [ITU-T 695 G.709 v0.83]. For the SDH/Sonet particular case, the section DCC 696 bytes or other SDH/Sonet unused overhead bytes. 698 For the out-of-band, the proposed transport mechanism is based on a 699 dedicated Optical Supervisory Channel (i.e. the control-channel) 700 carried on the same physical link as the one carrying the data- 701 channels. However, the OSC channel is only available at the IaDI-NNI 702 but not at the IrDI-NNI. For the SDH/Sonet particular case, a TDM 703 sub-channel can be entirely allocated for this purpose. 705 5.2.2 Additional Identification-related Discovery 707 The Carrier ID (CID) defines the identity of the carrier to which 708 the ONE element belongs. 710 The Privacy ID (PrID) determines whether a NNI interface is 711 untrusted or trusted. 713 These identifiers are provisioned by the administrative authority of 714 the optical network and exchanged during the neighbor identity 715 discovery process: 716 - ONE discovers the Carrier ID attached to a specific ONE element 718 Papadimitriou et al. Expires May 2001 14 719 - ONE discovers the Privacy ID attached to a specific ONE internal- 720 point 722 The Carrier ID uniquely determines the owner of a signaling message 723 when travelling over IrDI-NNI signaling channels between optical 724 networks. 726 The Privacy ID makes the distinction between trusted and untrusted 727 NNI interfaces: generally, there is a trust relationship between 728 IaDI-NNI interfaces and an untrusted relationship between IrDI-NNI 729 interfaces. The privacy level (trusted or untrusted) defines the 730 confidentiality level of the information exchanged through the 731 corresponding NNI interfaces. 733 6. NNI Topology and resource Distribution Protocol 735 The Topology and resource Distribution Protocol (TrDP) is the 736 mechanism provided to initially exchange and distribute the 737 discovered logical-port related information of the ONE included in 738 an optical sub-network. This protocol is fundamentally running 739 across intra-domain NNI interfaces. 741 The TrDP protocol is an IGP concept-based protocol. However, since 742 the focus of this document is to enlarge the scope of the current 743 available paradigms and concepts, we do not refer explicitly either 744 to an existing extended routing protocol or to the need of a new IGP 745 routing protocol. This means that the requirements detailed within 746 this section must be applicable to any kind of existing IGP routing 747 protocols. However, within the first version of this proposal, the 748 specifications of this protocol implicitly refer to an OSPF-like 749 protocol. Hence, through the remaining sections of this document, we 750 use the term OSPF-Like protocol to refer to this routing protocol. 752 The TrDP protocol is based on the following concepts: 753 - maintaining the neighbor relationship with peering ONEs 754 - flooding of the ONEs logical link adjacencies 755 - flooding of the ONEs logical link state 756 - flooding of the ONEs logical link related information 758 These information are used to maintain three databases: the neighbor 759 database, the local ONE database and the topology ONE database. 761 Depending on the flooding scope, the ONE information distributed 762 throughout the optical sub-network is related to: 763 - the logical-port identification information, 764 - the logical-port resource information (available and reservable 765 bandwidth as well as the associated priority), 766 - the logical-link service and routing information (protection 767 level(s) and the associated priority as well as the internal link 768 diversity) 770 Papadimitriou et al. Expires May 2001 15 771 For the ONE termination-point, one additional information is flooded 772 throughout the optical sub-network: the logical address to 773 termination-point ID mappings. 775 6.1 Transport mechanisms 777 A transport mechanism is provided between IaDI-NNI interfaces to 778 enable the distribution of the topology information within or 779 between optical sub-networks. 781 These transport mechanisms are the same than those defined for the 782 NNI signaling and described in section 4. Other specific transport 783 mechanisms related to the TrDP protocol are TBD. 785 6.2 Protocol requirements 787 The Topology and resource Distribution Protocol (TrDP) requirements 788 are related to those imposed for NNI signaling and control-channels. 789 For each of those requirements, the corresponding mechanism to 790 fulfil these requirements is specified: 792 - Between the IaDI-NNIs, the TrDP protocol must be IP-based, the NNI 793 IPv4 address is the one uniquely associated to the internal or 794 boundary ONE. The knowledge of the NNI IPv4 address could be static 795 or dynamic. 797 - Availability and maintenance of the neighbor relationships that 798 define the adjacencies between ONEs is provided by a `classic' 799 version of the Hello protocol including flow-control and checksum. 801 - Reliability of the TrDP protocol is provided by means of a 802 sequenced acknowledgement mechanism. 804 - Reliability of the information flooded could be based on the use 805 of an aging-time, a payload checksum, a flow-control mechanism based 806 on packet sequence numbering and the identification of the source 807 ONE and the identification of the point this payload describes. 809 - The time to acquire the consistency of the topology database 810 within a given optical sub-network and convergence time during 811 `topological modifications' should be reduced in order to allow 812 rapid changes within the optical sub-network. 814 - The authentication mechanism provided between peering ONE's 815 constituting a neighbor relationship within a given instance of the 816 TrDP protocol, could be based on the Message Digest 5 authentication 817 process. 819 - The confidentiality of the information flooded throughout the 820 network can be achieved by encrypting the IP packet payload. 822 Papadimitriou et al. Expires May 2001 16 823 In addition to these requirements, the topology distribution 824 protocol must meet the requirements already defined for the NNI 825 control-channels. 827 6.3 TrDP Discovery Protocol 829 The TrDP protocol is closely related to the Neighbor discovery 830 protocol and includes the following basic discovery mechanisms: 831 - Logical-port resource discovery (section 6.3.1) 832 - Logical-port address discovery (section 6.3.2) 833 - Logical-port service discovery (section 6.3.3) 835 The concepts and terminology concerning the logical-port and 836 internal-point are the same the one defined in the section 5.1. 838 6.3.1 Logical-port: Resource Discovery 840 The logical-port resource discovery process is defined as the 841 mechanism provided to exchange the information related to the 842 identification and the available resources for all of the logical 843 ports connecting two neighboring ONEs. 845 The proposed mechanism implicitly includes the logical-port identity 846 registration process since each of the logical-ports sends its 847 corresponding identifier during the same process. 849 The logical-port resource discovery process includes Framing- 850 Bandwidth capacity of each of the logical-ports connecting two 851 neighboring ONEs and for TDM capable interfaces the transparency- 852 level supported by the ONE logical-ports. 854 The NNI signaling transport mechanisms considered here are the in- 855 band (case 1) and the out-of-band (case 2) mechanisms; extensions 856 for the out-of-network (case 3) mechanisms are also considered. 858 Case 1: In-band transport 860 The Framing-Bandwidth resource discovery process is realized by 861 means of a PPP over HDLC-like framing [RFC 1662] session established 862 between the ONEs NNI interfaces. The corresponding mechanism should 863 include the following steps: 865 - During this PPP session, the Framing-Bandwidth capacity of each of 866 the logical-ports connecting neighboring ONEs is exchanged between 867 the source ONE and the destination ONE. 869 If the generic logical structure of a physical port does not 870 include channel (i.e. fiber-switch capable port) or sub-channel 871 (i.e. lambda-switch capable port) the corresponding identifiers are 872 not specified. 874 Papadimitriou et al. Expires May 2001 17 875 - The response about the Framing-Bandwidth of each logical-port are 876 directed from the destination ONE to the source ONE. 878 The proposed mechanism implicitly includes the Internal-point 879 Identity registration process since each of the logical-port 880 information is sent with its corresponding identifier (i.e. the 881 internal-point identifier including the ONE IPv4 address to which 882 the logical-port belongs) during the same process. 884 Case 2: Out-of-band transport 886 The mechanism described in the previous case needs an additional 887 identifier since the out-of-band mechanism must know the port ID to 888 which the records refers. 890 The concept is the same as the one described in the previous case. 891 However in order to distinguish between the framing-bandwidth 892 capacity of each of the registered ports, a list containing the 893 physical port identification is sent from the source ONEm NNI 894 interface to the destination ONEn NNI interface. 896 The response sent by the destination ONE and directed to the source 897 ONE contains a list containing the Framing-Bandwidth of each 898 logical-port included within the physical connecting peering ONEs. 900 Consequently, and compared to the previous case, only one additional 901 information (the port ID correspondence) per port must be provided 902 between the ONEs. 904 Case 3: Out-of-Network Extensions 906 All the processes described here except the Internal-port 907 registration process can be extended to the out-of-network signaling 908 transport by considering one additional hierarchy level: the first 909 level refers to the IP address of the IaDI-NNI connected to the 910 neighboring IaDI-NNI and the second level to the ONE-to-ONE port 911 correspondence. 913 - Additional Resource-related Discovery - 915 Some parameters, such as the SDH/SONET transparency level and the 916 support of concatenation (virtual or continuous concatenation) could 917 be exchanged for TDM capable ports during the Logical-port Resource 918 Discovery process. 920 Concerning the G.LSP directionality, we do not consider the exchange 921 of information related to the support of bi-directional G.LSPs. 923 6.3.2 Logical-port: Address Discovery 925 Internal-point identifiers may be addressed through the use of 926 logical addresses. Such kind of mechanism has already been defined 928 Papadimitriou et al. Expires May 2001 18 929 for the addressing of the client CNE termination-point identifiers 930 [OIF2000.261.1]. 932 However, this proposal does not in its current version consider the 933 logical addressing of logical-ports. 935 6.3.3 Logical-port: Service Discovery 937 Logical-port Service Discovery is the last step included in the TrDP 938 discovery protocol. Transport mechanisms for the logical-port 939 service discovery are the same than those defined during for the 940 previous logical-port resource discovery. An in-band or out-of-band 941 IP over PPP session between the NNI interfaces of neighboring ONEs 942 could be the transport mechanism used by the logical-port service 943 discovery. 945 The logical-port service discovery mechanism provides the following 946 information through the signaling channel set up between NNIs of 947 neighboring ONEs: 949 6.3.3.1 Link-Protection Service Discovery 951 During the link-protection service discovery process, neighboring 952 ONEs exchange the information related to link-protection level 953 supported by their directly connected logical-ports. The related 954 information is initially manually provisioned and then exchanged. 956 Link-Protection levels could be one (or more than one) of the 957 following: 958 - Unprotected 0:1 959 - Dedicated 1+1 Protection 960 - Dedicated 1:1 Protection 961 - Shared Protection: 1:N - M:N 963 Link-Protection level implicitly refers to the protection levels 964 associated to the data-channel links between two neighboring ONEs. 965 Consequently, per data-channel direction, we consider one source 966 link-protection level (for the transmit direction) and one 967 destination link-protection level (for the receive direction). 969 The corresponding discovery process occurs between two neighboring 970 ONEs and includes a request/response through which the peering ONEs 971 exchange their supported logical-port protection levels. 973 After this discovery process, a `reservation' process requested 974 between neighboring ONEs may be considered. The corresponding 975 detailed mechanism is TBD. 977 6.3.3.2 Link-Priority Service Discovery 979 During the link-priority service discovery process, the neighboring 980 ONEs exchange the following priority-related service parameters: 982 Papadimitriou et al. Expires May 2001 19 983 1. Link-Priority (and priority classes) and Link-Preemption type 984 (setup and recovery) supported by the ONEs are exchanged during the 985 Link-Priority service discovery. 987 The link-priority concept is associated to: 988 - the available bandwidth per port, per channel or per sub-channel 989 and the bandwidth reservation during the G.LSP creation process. 990 - the link protection level per port supported by the ONE 992 During the G.LSP creation process, the available bandwidth reserved 993 for the G.LSP during this process is related to the bandwidth 994 priority of the link through which the lighpath is created. The same 995 mechanism takes place for the protection level requests during the 996 G.LSP creation process. 998 The priority of a link could belong to a link priority-class. For 999 the ONEs that do not support the priority-class processing, the link 1000 priority must be set to a default link priority class (Class 1) 1001 [ENH-LSPS]. 1003 For the ONEs, which do not support the link priorities and the link 1004 priority-class processing, a default link priority must also be 1005 defined. These default values are defined in order to ensure the 1006 interoperability between ONEs at IaDI-NNI interfaces and between 1007 optical sub-networks at IrDI-NNI interfaces. 1009 Note: if the link-priority service is not supported by an ONE, the 1010 link-priority classes service won't be supported by this ONE. 1012 2. Preemption (i.e. pre-emptability) of a link is related to the 1013 priority of the link. Preemption type includes the setup (or 1014 creation) preemption, the recovery preemption as both the setup and 1015 recovery preemption the pre-emptability of a G.LSP. 1017 The corresponding mechanism specifies whether a given link used by a 1018 lower-priority G.LSP can be preempted by a G.LSP of higher priority 1019 if the resource used by the lower-priority G.LSP need to be used 1020 during the setup and/or the recovery of this higher priority G.LSP. 1022 6.3.3.3 Routing-related Service Discovery 1024 The routing-related service discovery is mainly based on the 1025 diversity-related options support of the boundary and internal ONEs: 1027 The diversity of a G.LSP is defined as the list of N G.LSPs ID from 1028 which a given G.LSP (so a given G.LSP ID) must be physically diverse 1029 from. 1031 Several type of resource from which a given G.LSP could be 1032 physically diverse from are defined. These resources have their 1033 counter-parts within the optical network. Each ONE included into an 1035 Papadimitriou et al. Expires May 2001 20 1036 optical network could support the following resources from which a 1037 given G.LSP must be diverse from: 1038 - Fiber segments 1039 - Fiber sub-segments 1040 - Fiber links 1041 - Shared Risk Link Group (SRLG) 1043 When executing the G.LSP service request from the client CNE (remind 1044 here that the client CNE does only knows about the G.LSPs he has 1045 already established) the client CNE can only reference a G.LSP M 1046 from which the new G.LSP N should be diverse. The ONE will interpret 1047 this request by considering the Shared Risk Link Group _ SRLG of the 1048 G.LSP M and find a physical route for the G.LSP N whose SRLG is 1049 diverse from. 1051 The associated discovery mechanism is straightforward: the ONE 1052 supports or does not support SRLG diversity. However, the 1053 corresponding detailed mechanisms are currently under definition. 1055 6.4 TrDP Protocol Mechanisms 1057 A dedicated mechanism is considered here to distribute the 1058 topological information discovered through the TrDP discovery 1059 protocol. The topology distribution protocol is based on a reliable 1060 flooding of the ONE state, information and adjacencies into the 1061 optical sub-network. 1063 Since the ONE's adjacencies are discovered through the neighbor 1064 distribution protocol, they control the distribution of the 1065 topological information of the optical sub-network. The ONE's 1066 advertisements fully describe or summarize the discovered 1067 information of the ONE's logical-ports. The topology database is the 1068 collection of all ONE's advertisements. 1070 6.4.1 ONE Advertisements and Flooding Process 1072 Each ONE belonging to an optical sub-network originates ONE 1073 advertisements. These advertisements describe the state and 1074 information related to the ONE's logical-ports (i.e. ONE logical- 1075 links). All of the ONE logical links must be described in a single 1076 ONE advertisement. 1078 Inside an optical network (i.e. Autonomous System), three types of 1079 ONE advertisements are considered: link-local, intra-area and inter- 1080 area ONE advertisements; a flooding rule is associated to each of 1081 these ONE advertisements: 1082 - Link-local ONE advertisements: flooding scope limited to adjacent 1083 ONEs 1084 - Intra-area ONE advertisements: flooding scope limited to an area 1085 - Inter-area ONE advertisements: flooding scope covers a whole 1086 autonomous-system 1088 Papadimitriou et al. Expires May 2001 21 1089 The flooding mechanism of the TrDP protocol distributes and 1090 synchronizes the local ONE database and the topology database 1091 between ONE IaDI-NNI interfaces. 1093 The topological information flooded throughout the optical sub- 1094 network is related to the logical-port properties-related 1095 information and their associated logical-links: 1096 - the logical-port identifier (which populates only the local ONE 1097 database) 1098 - the logical-port resource: available and reservable bandwidth 1099 (minimum and maximum) as well as the associated priority level(s) 1100 - the logical-link protection level(s) and the associated priority 1101 level(s) 1102 - the link diversity (the SRLG groups included within the link to 1103 which the corresponding ONE internal-point belongs to) 1104 - and for logical-ports corresponding to ONE termination-points, the 1105 mapping between the ONE termination-point identifier and the 1106 corresponding CNE logical address 1108 6.4.2 Topology Database and Local ONE Database 1110 The collected ONE advertisements of all ONEs included within the 1111 optical sub-network constitutes the topology database. 1113 The consistency of the topology database is directly related to the 1114 consistency of the information flooded through the ONE 1115 advertisements and the frequency at which these advertisements are 1116 generated. In turn, these criteria determine the convergence time of 1117 the topology database throughout a given optical sub-network. 1119 The consistency of the topology database is not directly related to 1120 the performance of the NNI signaling channels. Once the goodput of 1121 these signaling channels is known and advertisement frequency has 1122 been configured, the performance of the signaling channel does not 1123 play a role anymore concerning the consistency of this database. 1125 The detailed information concerning the logical-ports properties and 1126 features and exchanged between directly connected ONEs, constitutes 1127 the local ONE database: 1129 1. Logical-port 1131 The restriction of the topology database to the complete information 1132 related logical-port and their corresponding links gives a logical 1133 view of the optical network physical links between ONEs. The 1134 detailed information related to logical-ports connecting peering 1135 ONEs forms the local ONE database. 1137 Within the local ONE database, the identity parameters are 1138 related to the state of the corresponding logical-port and 1139 adjacency. Consequently, the corresponding state is determined 1140 whether or not the logical-port is active or inactive. 1142 Papadimitriou et al. Expires May 2001 22 1143 Moreover, a G.LSP could be represented as a set of logical-port IDs 1144 and thus as a set of internal-point IDs (concatenation of the ONE IP 1145 Address and Logical-port ID) starting from the source termination- 1146 point ID and terminating at the destination termination-point ID: 1148 [{TP-Id _ IP-Id},{IP-Id _ IP-Id},_,{IP-Id _ IP-Id},{IP-Id _ TP-Id}] 1150 Consequently, the topological information related to the logical- 1151 ports, flooded within the link-local ONE advertisements, is the 1152 following: 1153 - the logical-port identifier (i.e. logical-link identifier) and its 1154 status 1155 - the G.LSP identifier (the set of internal-point IDs) and its 1156 corresponding status 1158 Since the collected ONE advertisements of all neighboring ONEs 1159 included into the same optical sub-network constitutes the local ONE 1160 database, this database has the following entries when the logical- 1161 port identity discovery process is convergent: 1163 Local ONE Neighbor ONE 1 State 1164 --------------------------------------------------------------- 1165 Logical-port ID Logical-port ID Active 1166 Logical-port ID Logical-port ID Inactive 1168 Local ONE Neighbor ONE N State 1169 --------------------------------------------------------------- 1170 Logical-port ID Logical-port ID Active 1171 Logical-port ID Logical-port ID Inactive 1173 After the initial convergent state, an ONE update will only be 1174 generated in the following cases: 1175 - the status of the logical-port has changed 1176 - the status of the G.LSP using this logical-port has changed 1178 2. Logical-port Resource 1180 Within the local ONE database, the logical-port resource-related 1181 information includes the available bandwidth (AB) and the minimum 1182 and maximum Reservable Bandwidth (MinRB and MaxRB) as well as the 1183 associated priority (AB[p], MinRB[p] and MaxRB[p]). The priority 1184 value is the lowest priority at which this bandwidth is available. 1186 This resource-related information is available in the local ONE 1187 database for each of the logical-ports connected to direct peer 1188 ONEs. So, the logical-port resource information is represented by 1189 the following entries into the local ONE database: 1191 Local ONE Neighbor ONE 1 State 1192 -------------------------------------------------------------------- 1193 LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active 1195 Papadimitriou et al. Expires May 2001 23 1196 LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Inactive 1198 Local ONE Neighbor ONE 2 State 1199 -------------------------------------------------------------------- 1200 LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active 1201 LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active 1203 In these database entries: 1204 - AB values are defined as the framing-bandwidth parameter 1205 - RB values are defined as the framing-bandwidth parameter 1207 When the boundary ONE receives a G.LSP create request, and the CSPF 1208 has established the corresponding path into the optical sub-network, 1209 the boundary ONE waits until receiving the G.LSP create response 1210 message to update the local database and flood the ONE updates 1211 throughout the optical sub-network. 1213 For instance, if the G.LSP is requested with 1 unit of bandwidth and 1214 with priority r then the local database is updated as follows: 1216 Local ONE Neighbor ONE 1 1217 -------------------------------------------------------------------- 1218 LP-ID AB-1[p] MinRB[p] MaxRB-1[p] LP-ID AB-1[q] MinRB[q] MaxRB-1[q] 1219 LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] 1221 If an additional G.LSP create request with 4 units of bandwidth and 1222 a 4:1 relationship exists between the local and the neighbor ONE, 1223 then the local database is updated as follows: 1225 Local ONE Neighbor ONE 2 1226 -------------------------------------------------------------------- 1227 LP-ID AB-1[p] MinRB[p] MaxRB-1[p] LP-ID AB-4[q] MinRB[q] MaxRB-4[q] 1228 LP-ID AB-1[p] MinRB[p] MaxRB-1[p] 1229 LP-ID AB-1[p] MinRB[p] MaxRB-1[p] 1230 LP-ID AB-1[p] MinRB[p] MaxRB-1[p] 1232 3. Logical-link Protection 1234 The related mechanisms are TBD. 1236 4. Link Diversity 1238 The related mechanisms are TBD. 1240 6.4.3 Flooding Rules 1242 To avoid an exponential increase of the ONE advertisements through 1243 the optical network, the following flooding rules are applied: 1245 Papadimitriou et al. Expires May 2001 24 1246 1. Flooding link-local advertisements 1248 Link-local advertisements are flooded only between neighboring ONE. 1249 The information included within the corresponding ONE advertisement 1250 determines for any logical-link connected to a given neighbor: 1251 - the logical-link identification: the IPv4 address of the ONE and 1252 the identifier to which the local logical-port is connected 1253 - the logical-link resource: available bandwidth, minimum and 1254 maximum reservable bandwidth and the associated priority 1255 - the logical-link services: protection and the associated priority 1256 _ diversity support for the corresponding link 1258 For the logical-links corresponding to ONE termination-points, one 1259 additional information is flooded throughout the optical sub- 1260 network: the reachability information which includes the client CNE 1261 logical address corresponding to this termination-point. 1263 Consequently, the ONE has the complete information concerning the 1264 identity, the resources and the services offered by the neighboring 1265 ONE logical links. This information constitutes the local ONE 1266 database (cf. Section 6.4.2). 1268 2. Flooding intra-area advertisements 1270 For each of the ONE's adjacency, one intra-area ONE advertisement is 1271 generated and flooded within the corresponding area. The information 1272 included in this ONE advertisement is summarized as follows: within 1273 an intra-area ONE advertisement, the logical-links (logical-port[n]) 1274 are grouped regarding the common resource and service properties 1275 they share: 1276 - Unreserved Bandwidth: AB[p] _ Sum(Reserved Bandwidth[p]) 1277 - Min Reservable Bandwidth: MinRB[p] 1278 - Associated Link Protection level: Protection[p] 1279 - Preemption types supported: Setup and/or Recovery 1280 - Routing diversity-related information 1282 For boundary ONE, the intra-area advertisement also includes the CNE 1283 termination-point ID (and logical address to CNE termination-point 1284 ID mapping) and the associated status. 1286 3. Flooding inter-area advertisements 1288 For each area one inter-area ONE advertisement is generated and 1289 flooded within the corresponding autonomous-system. The information 1290 included in this ONE advertisement is summarized as follows: within 1291 the inter-area advertisement, logical-links (logical-port[n]) are 1292 grouped by considering the common resource and service properties 1293 they share, except the routing diversity-related information: 1294 - Unreserved Bandwidth: AB[p] _ Sum(Reserved Bandwidth[p]) 1295 - Min Reservable Bandwidth: MinRB[p] 1296 - Associated Link Protection level: Protection[p] 1297 - Preemption types supported: Setup and/or Recovery 1299 Papadimitriou et al. Expires May 2001 25 1300 In this case, the routing diversity-related information is not 1301 included within the corresponding advertisement. A summarization of 1302 the routing diversity-related information is TBD. 1304 By classifying the advertisement types, the amount of information 1305 flooded within an area and an autonomous-system is drastically lower 1306 than the amount of information to be flooded without such 1307 summarization of the information. 1309 6.4.4 ONE Advertisement Type 1311 We can define in addition to source ONE and destination ONE the 1312 following terms: 1313 - the intermediate ONE: ONE included within an area or an area 1314 border ONE; this ONE corresponds to an internal ONE including only 1315 IaDI-NNI interfaces 1316 - the boundary ONE: autonomous-system border ONE; this ONE 1317 corresponds to an ONE containing at least one IrDI-NNI interface 1319 The ONE advertisement type includes the distribution mechanism for 1320 flooding the corresponding information throughout a given optical 1321 sub-network (or network depending on the type of advertisement). 1323 The ONE advertisement type of the ONE advertisement identifies the 1324 advertisement's range of topological distribution. This range is 1325 referred to as the Flooding Scope. 1327 The ONE advertisements have a flooding scope associated with them so 1328 that the scope of flooding may be link-local (type 1), intra-area 1329 (type 2) or the entire autonomous-system (type 3). 1331 The flooding scope of each of the ONE advertisement types are: 1332 - The type-1 denotes a link-local scope. ONE advertisements with a 1333 link-local scope are not flooded beyond the local IaDI-NNI link 1334 - The type-2 denotes an intra-area scope. ONE advertisements with a 1335 intra-area scope are not flooded beyond the area where they are 1336 originated. 1337 - The type-3 denotes an inter-area (or AS-wide) scope. ONE 1338 advertisements with an inter-area scope can be flooded throughout 1339 the entire Autonomous System. 1341 6.4.5 Additional mechanisms 1343 The Topology distribution protocol could also include the following 1344 mechanism: 1346 - If we consider that the IP control plane signaling protocol (cf. 1347 Section 7) is based on CR-LDP Label Request (or RSVP Path message) 1348 and Label Mapping messages (or RSVP Resv message) then label 1349 piggybacking could be included in the proposed version of the TrDP 1350 Protocol. 1352 Papadimitriou et al. Expires May 2001 26 1353 - Other additional mechanisms are TBD. 1355 7. NNI Signaling Mechanisms and Protocols 1357 This section describes the NNI signaling mechanism needed internally 1358 to the optical network in order to provide the optical network 1359 clients the G.LSP signaling services at the UNI. 1361 We first remind the UNI G.LSP signaling services, then consider the 1362 NNI signaling requirements and the potential NNI signaling protocols 1363 and finally detail the NNI signaling messages. 1365 7.1 UNI G.LSP Signaling Services 1367 As defined into [MPLS-OUNI] and the UNI v1.0 OIF proposal 1368 [OIF200.125.2], four G.LSP signaling services are considered: 1369 - G.LSP creation 1370 - G.LSP modification 1371 - G.LSP deletion 1372 - G.LSP status 1374 Additionally, the UNI-N may send a G.LSP notification message to 1375 notify the UNI-C about the current status of a G.LSP. This G.LSP 1376 notification message as to be considered has an unsolicited message. 1378 For each of these services, the following primitives should be 1379 available: 1380 - Request messages: 1381 . G.LSP create request message 1382 . G.LSP modify request message 1383 . G.LSP delete request message 1384 . G.LSP status request message 1385 - Response messages: 1386 . G.LSP create response message 1387 . G.LSP modify response message 1388 . G.LSP delete response message 1389 . G.LSP status response message 1390 - Unsolicited messages: G.LSP notification 1392 Note that the G.LSP status service could be initiated either by 1393 Client UNI (UNI-C) or by Network UNI (UNI-N). 1395 7.2 NNI Signaling Requirements 1397 NNI Signaling requirements are related to the requirements imposed 1398 for in-band, out-of-band and out-of-network NNI control-channels. 1399 For each of those requirements, the corresponding mechanism to 1400 fulfil these requirements is specified: 1402 - Between the NNI interfaces, the signaling protocol must be IP- 1403 based, the NNI IPv4 address is the one uniquely associated to the 1405 Papadimitriou et al. Expires May 2001 27 1406 internal or boundary ONE (respectively ONC) corresponding interface. 1407 The knowledge of the NNI IPv4 address could be static or dynamic. 1409 - When ONE (respectively ONC) is connected through multiple 1410 interfaces to a neighboring ONE (i.e. there are multiple in-band 1411 and/or out-of-band links between the corresponding ONEs or multiple 1412 out-of-network transport links between the corresponding ONCs), only 1413 one NNI signaling -channel must be logically defined between ONEs 1414 signaling interfaces (respectively ONC signaling interfaces). 1416 - Availability of the NNI signaling-channel mechanism is based on 1417 PPP Multilink protocol for in-band/out-of-band channels and a 1418 dedicated mechanism (TBD) for out-of-network channels. 1420 - Reliability of the NNI signaling-channel mechanism is provided 1421 through the use of a dedicated TCP/IP session on top of a PPP 1422 Multilink session if supported by the peering ONE equipment 1423 (respectively ONC equipment). 1425 - The security of the NNI signaling-channel and interfaces is 1426 provided through the use of CHAP protocol and IPSEC header 1427 authentication (and optionally encryption). Security-level of the 1428 NNI signaling-channels and interfaces depends on the relationship 1429 between peering ONEs (resp. ONC) i.e. whether the NNI signaling 1430 channel is established between untrusted or trusted interfaces. 1432 - The performance of the NNI signaling -channel must be guaranteed 1433 through the definition of a minimum round-trip time for a given 1434 payload size. Control of the NNI signaling -channel performance is 1435 greatly facilitated by the use of the TCP Protocol. 1437 7.3 NNI Signaling Paradigm and Protocols 1439 The signaling paradigm considered implicitly throughout this 1440 document is based on the G.MPLS signaling concept. However, we do 1441 not refer to a specific implementation of the paradigm in order to 1442 keep the focus of this document on a higher level than the one 1443 proposed in the [G.MPLS] draft. 1445 However, since of the aim of the proposal is to determine which 1446 requirements and mechanisms does the G.MPLS signaling protocol and 1447 its implementation need to fulfil we do refer to specific functional 1448 aspects included within the available specifications. 1450 This proposal considers the constraint-based extension of the label 1451 distribution protocol (CR-LDP) and the Resource reSerVation Protocol 1452 (RSVP) including its Traffic-Engineering extensions (RSVP-TE) as 1453 potential NNI signaling protocol implementations. 1455 7.4 NNI Signaling Interfaces 1457 Papadimitriou et al. Expires May 2001 28 1458 This section defines the NNI signaling interfaces. In order to 1459 describe these messages and the corresponding mechanisms, we define 1460 the following concepts for a given G.LSP service request/response: 1462 - Source IaDI-NNI: the source IaDI-NNI is defined as the IaDI-NNI 1463 interface belonging to the ONE (or ONC) whose UNI-N has the source 1464 UNI-C as client. The source IaDI-NNI sends the G.LSP service message 1465 within the optical sub-network. 1467 - Destination IaDI-NNI: the destination IaDI-NNI is defined as the 1468 IaDI-NNI interface belonging to the ONE (or ONC) whose UNI-N has the 1469 destination UNI-C as client. The destination ONE is the receiver of 1470 the G.LSP service message within the optical sub-network. 1472 - Intermediate IaDI-NNI: the intermediate IaDI-NNI interface is 1473 defined as the IaDI-NNI interface belonging to an ONE (or ONC) which 1474 does not include any UNI-N interface. 1476 - Boundary IaDI-NNI: the boundary IaDI-NNI interface is a particular 1477 case of an intermediate IaDI-NNI interface belonging to an ONE (or 1478 ONC) which includes a IrDI-NNI interface. 1480 - Source IrDI-NNI: the IrDI-NNI interface belonging to a boundary 1481 ONE (or ONC) included within the optical network including the 1482 source IaDI-NNI interface. 1484 - Destination IrDI-NNI: the IrDI-NNI interface belonging to a 1485 boundary ONE (or ONC) included within the optical network including 1486 the destination IaDI-NNI interface. 1488 - Intermediate IrDI-NNI: the IrDI-NNI interface belonging to a 1489 boundary ONE (or ONC) included within an optical network which does 1490 include neither the source IrDI-NNI interface nor the destination 1491 IrDI-NNI interface. 1493 This proposal covers both distributed and centralized approaches. 1494 For the latter, the mappings between the kind of NNI interface and 1495 the centralized model are defined by considering a unique ONC 1496 controller per optical sub-network. 1498 For the centralized model we have the following equivalence between 1499 ONC and their supported interfaces (= means on _same ONC 1500 including_): 1501 - Intra-domain signaling within an optical network: 1502 Source IaDI-NNI = Intermediate IaDI-NNI = Destination IaDI-NNI 1503 - Inter-domain signaling between optical networks 1504 Source IaDI-NNI = Intermediate IaDI-NNI (sub-network 1) 1505 _ 1506 Intermediate IaDI-NNI (sub-network i) = Source IrDI-NNI (sub- 1507 network i) 1508 _ 1509 Destination IrDI-NNI (sub-network j) = Intermediate IaDI-NNI (sub- 1511 Papadimitriou et al. Expires May 2001 29 1512 net j) 1513 _ 1514 Intermediate IaDI-NNI (sub-network n) = Destination IaDI-NNI (sub- 1515 net n) 1517 7.5 NNI Signaling Messages 1519 This section defines the NNI signaling messages. In order to 1520 describe these messages and the corresponding mechanisms, we 1521 describe the corresponding signaling message directions. 1523 To each of the UNI signaling message corresponds at least one NNI 1524 signaling message. The mapping of these messages into their NNI 1525 counter-part and their associated directionality are described in 1526 the next sub-sections. 1528 7.5.1 G.LSP Creation 1530 The G.LSP creation process includes the G.LSP create request and the 1531 G.LSP create response. 1533 7.5.1.1 G.LSP create request 1535 When located within a given optical sub-network or between optical 1536 sub-networks, the lightpath create request message is routed through 1537 the following generic paths: 1538 - UNI: Source UNI-C -> UNI-N 1539 - NNI: Source IaDI-NNI -> _ -> Intermediate IaDI-NNI 1540 - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI 1541 - NNI: Intermediate IaDI-NNI -> _ -> Destination IaDI-NNI 1542 - UNI: UNI-N -> Destination UNI-C 1544 The following figure describes the G.LSP create request message sent 1545 by the initiating UNI-C to the UNI-N and the corresponding message 1546 sent by the initiating IaDI-NNI interface after the treatment 1547 performed on this message. The latter message also corresponds to 1548 the one sent between intermediate IaDI-NNI interfaces and between 1549 IrDI-NNI interfaces. 1551 +-------------------------------+ 1552 | ONE Source | 1553 | Termination-point ID | 1554 +-------------------------------+ 1555 | ONE Destination | 1556 | Termination-point ID | 1557 +-------------------------------+ +-------------------------------+ 1558 | CNE Source | | Explicit Route | 1559 | Termination-point ID | | | 1560 +-------------------------------+ +-------------------------------+ 1561 | CNE Destination | | Record Route (optional) | 1562 | Termination-point ID | | | 1563 +-------------------------------+ +-------------------------------+ 1565 Papadimitriou et al. Expires May 2001 30 1566 | Source User Group ID | | Source User Group ID | 1567 +-------------------------------+ +-------------------------------+ 1568 | Destination User Group ID | | Destination User Group ID | 1569 +-------------------------------+ +-------------------------------+ 1570 | Contract ID (optional) | | Carrier ID (optional) | 1571 +-------------------------------+ +-------------------------------+ 1572 | G.LSP ID | | G.LSP ID | 1573 +-------------------------------+ +-------------------------------+ 1574 | Bandwidth-Framing | | Bandwidth-Framing | 1575 +-------------------------------+ +-------------------------------+ 1576 | SDH/SONET Options (optional) | | SDH/SONET Options (optional) | 1577 +-------------------------------+ +-------------------------------+ 1578 | Optical (optional) | | Optical (optional) | 1579 +-------------------------------+ +-------------------------------+ 1580 | Directionality (optional) | | Directionality (optional) | 1581 +-------------------------------+ +-------------------------------+ 1582 | Max Signaling Delay (optional)| | Max Signaling Delay (optional)| 1583 +-------------------------------+ +-------------------------------+ 1584 | Priority-Preemption (optional)| | Priority-Preemption (optional)| 1585 +-------------------------------+ +-------------------------------+ 1586 | Network Protection (optional) | | Network Protection (optional) | 1587 +-------------------------------+ +-------------------------------+ 1588 | Side Protection (optional) | | Side Protection (optional) | 1589 +-------------------------------+ +-------------------------------+ 1590 | Diversity (optional) | | Diversity (optional) | 1591 +-------------------------------+ +-------------------------------+ 1592 | Service-related (optional) | | Service Related (optional) | 1593 +-------------------------------+ +-------------------------------+ 1595 Figure 4: G.LSP Create request 1597 Within this figure, the following parameters have a specific 1598 significance: 1599 - the SDH/SONET parameter is only mandatory for SDH/SONET 1600 - the Max Signaling Delay is defined as the Maximum Signaling 1601 Request Delay 1602 - the explicit route parameter is detailed in section 7.6.2 1603 - the record route parameter is detailed in section 7.6.3 1605 The carrier ID, the diversity and the service-related parameters are 1606 only used to set up G.LSPs whose destination termination-point ID 1607 are located in another administrative domain than one to which the 1608 source termination-point ID belongs need to be established. 1610 Consequently the generic G.LSP create request message sent between 1611 IaDI-NNI interfaces includes the following parameters: 1612 - ONE Source Termination-point ID 1613 - ONE Destination Termination-point ID 1614 - Explicit Route 1615 - Record Route (optional) 1616 - Source User Group ID 1617 - Destination User Group ID 1619 Papadimitriou et al. Expires May 2001 31 1620 - G.LSP ID 1621 - Bandwidth-Framing 1622 - SDH/SONET Options (optional) 1623 - Optical Options (optional) 1624 - Directionality (optional) 1625 - Max Signaling Delay (optional) 1626 - Priority-Preemption (optional) 1627 - Network Protection (optional) 1628 - Side Protection (optional) 1630 Notice: some of these parameters are still under study (mainly 1631 concerning the priority-preemption and protection parameters) 1633 1. Intra-Domain - G.LSP Creation Procedure 1635 The G.LSP creation procedure includes the procedure performed by the 1636 source, the intermediate and the destination IaDI-NNI interfaces. 1638 The main tasks to be performed by the source IaDI-NNI are: 1639 - calculate the route from the source ONE to the destination ONE by 1640 using the Constraint-Based Shortest Path First C-SPF Algorithm. 1641 - replace the CNE source and destination termination-point ID by ONE 1642 source and destination Termination-Point ID. 1643 - assign the identifier of the G.LSP and prepare the requested 1644 resources as indicated within the client request. 1646 The main tasks to be performed by the intermediate IaDI-NNI are: 1647 - prepare the requested resource as indicated within the G.LSP 1648 create request 1649 - remove the previous hop identifier included within the explicit 1650 route field and optionally append this value to the route record 1651 field 1653 The main tasks to be performed by the destination IaDI-NNI are: 1654 - replace the ONE source and destination termination-point ID by the 1655 CNE source and destination termination-point ID before forwarding 1656 the request to the corresponding client 1657 - remove the previous hop identifier included within the explicit 1658 route field and optionally append this value to the route record 1659 field 1660 - optionally register the route record field 1661 - prepare the requested resource as indicated within the G.LSP 1662 create request 1664 2. Inter-domain G.LSP Creation Procedure 1666 The G.LSP creation procedure should include the following steps: 1667 - Since the create request message may be sent over IrDI-NNI 1668 interfaces (meaning through separate administrative authority and 1669 thus between optical networks) some CAC control should be provided 1670 at the boundary ONE to control the identity (by means of the Carrier 1671 ID) of the requestor. 1673 Papadimitriou et al. Expires May 2001 32 1674 Other mechanisms are TBD. 1676 7.5.1.2 G.LSP create response 1678 The G.LSP create response is directed from the destination UNI-C to 1679 the source UNI-C through the following sequence: 1680 - UNI: Destination UNI-C -> UNI-N 1681 - NNI: Destination IaDI-NNI -> _ -> Intermediate IaDI-NNI 1682 - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI 1683 - NNI: Intermediate IaDI-NNI -> _ -> Source IaDI-NNI 1684 - UNI: UNI-N -> Source UNI-C 1686 The following figure describes the G.LSP create response message 1687 sent by the terminating UNI-C to the UNI-N and the corresponding 1688 message sent by the terminating IaDI-NNI after the treatment 1689 performed on this message: 1691 +-------------------------------+ 1692 | ONE Source | 1693 | Termination-point ID | 1694 +-------------------------------+ +-------------------------------+ 1695 | CNE Source | | ONE Destination | 1696 | Termination-point ID | | Termination-point ID | 1697 +-------------------------------+ +-------------------------------+ 1698 | CNE Destination | | Record Route (optional)* | 1699 | Termination-point ID | | | 1700 +-------------------------------+ +-------------------------------+ 1701 | Source User Group ID | | Source User Group ID | 1702 +-------------------------------+ +-------------------------------+ 1703 | Destination User Group ID | | Destination User Group ID | 1704 +-------------------------------+ +-------------------------------+ 1705 | Contract ID (optional) | | Carrier ID (optional) | 1706 +-------------------------------+ +-------------------------------+ 1707 | G.LSP ID | | G.LSP ID | 1708 +-------------------------------+ +-------------------------------+ 1709 | Result Code | | Result Code | 1710 +-------------------------------+ +-------------------------------+ 1712 Figure 5: G.LSP Create response 1714 * The route record parameter is detailed in section 7.6.3. 1716 7.5.2 G.LSP Deletion 1718 The G.LSP deletion process includes the G.LSP delete request and the 1719 G.LSP delete response. 1721 7.5.2.1 G.LSP delete request 1723 The G.LSP delete request is directed from the source UNI-C to the 1724 destination UNI-C through the following sequence: 1726 Papadimitriou et al. Expires May 2001 33 1727 - UNI: Source UNI-C -> UNI-N 1728 - NNI: Source IaDI-NNI -> _ -> Intermediate IaDI-NNI 1729 - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI 1730 - NNI: Intermediate IaDI-NNI -> _ -> Destination IaDI-NNI 1731 - UNI: UNI-N -> Destination UNI-C 1733 The following figure describes the G.LSP delete request message sent 1734 by the initiating UNI-C to the UNI-N and the corresponding message 1735 sent by the initiating IaDI-NNI interface after the treatment 1736 performed on this message. This message also corresponds to the one 1737 sent between intermediate IaDI-NNI interfaces and between IrDI-NNI 1738 interfaces. 1740 +-------------------------------+ +-------------------------------+ 1741 | CNE Source | | ONE Source | 1742 | Termination-point ID | | Termination-point ID | 1743 +-------------------------------+ +-------------------------------+ 1744 | CNE Destination | | ONE Destination | 1745 | Termination-point ID | | Termination-point ID | 1746 +-------------------------------+ +-------------------------------+ 1747 | Contract ID (optional) | | Explicit Route* | 1748 +-------------------------------+ +-------------------------------+ 1749 | G.LSP ID | | Carrier ID (optional) | 1750 +-------------------------------+ +-------------------------------+ 1751 | Result Code | | G.LSP ID | 1752 +-------------------------------+ +-------------------------------+ 1753 | Result Code | 1754 +-------------------------------+ 1756 Figure 6: G.LSP Delete request 1758 * Within the G.LSP delete request, the explicit route is implicitly 1759 defined by the G.LSP identifier since the intermediate ONEs keep 1760 track of the route established for the corresponding G.LSP. 1762 1. Intra-Domain - G.LSP Delete Procedure 1764 The G.LSP Delete procedure and other related mechanism are TBD. 1766 2. Inter-Domain - G.LSP Delete Procedure 1768 Since the delete message may be sent over IrDI-NNI interfaces 1769 (meaning through separate administrative authority and thus between 1770 optical networks) some CAC control should be provided at the 1771 boundary ONE to control the identity (by means of the Carrier ID) of 1772 the requestor. 1774 Other mechanisms are TBD. 1776 7.5.2.2 G.LSP delete response 1778 Papadimitriou et al. Expires May 2001 34 1779 The G.LSP delete request is directed from the destination UNI-C to 1780 the source UNI-C through the following sequence: 1781 - UNI: Destination UNI-C -> UNI-N 1782 - NNI: Destination IaDI-NNI -> _ -> Intermediate IaDI-NNI 1783 - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI 1784 - NNI: Intermediate IaDI-NNI -> _ -> Source IaDI-NNI 1785 - UNI: UNI-N -> Source UNI-C 1787 The following figure describes the G.LSP delete response message 1788 sent by the terminating UNI-C to the UNI-N and the corresponding 1789 message sent by the terminating IaDI-NNI after the treatment 1790 performed on this message: 1792 +-----------------------------+ +---------------------------------+ 1793 | CNE Source | | ONE Source | 1794 | Termination-point ID | | Termination-point ID | 1795 +-----------------------------+ +---------------------------------+ 1796 | CNE Destination | | ONE Destination | 1797 | Termination-point ID | | Termination-point ID | 1798 +-----------------------------+ +---------------------------------+ 1799 | G.LSP ID | | G.LSP ID | 1800 +-----------------------------+ +---------------------------------+ 1801 | Result Code | | Result Code | 1802 +-----------------------------+ +---------------------------------+ 1804 Figure 7: G.LSP Delete response 1806 The G.LSP delete request could also be generated by an IaDI-NNI 1807 during the creation (or recovery) of a high-priority G.LSP 1808 requesting some of the resources used by the low-priority G.LSP. 1809 This case is analyzed is the next section of this proposal. 1811 7.5.3 G.LSP Modification 1813 The G.LSP modification process includes the G.LSP modify request and 1814 the G.LSP modify response. 1816 Since this process must be non-destructive, it must be strictly 1817 controlled in order to allow only modifications concerning specific 1818 G.LSP parameters as G.LSP priority value, user-group identifier and 1819 maximum signaling delay. 1821 7.5.3.1 G.LSP modify request 1823 The G.LSP modify request is directed from the source UNI-C to the 1824 destination UNI-C through the following sequence: 1825 - UNI: Source UNI-C -> UNI-N 1826 - NNI: Source IaDI-NNI -> _ -> Intermediate IaDI-NNI 1827 - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI 1828 - NNI: Intermediate IaDI-NNI -> _ -> Destination IaDI-NNI 1829 - UNI: Intermediate UNI-N -> Destination UNI-C 1831 Papadimitriou et al. Expires May 2001 35 1832 The following figure describes the G.LSP modify request message sent 1833 by the initiating UNI-C to the UNI-N and the corresponding treatment 1834 performed on this message at the IaDI-NNI: 1836 +-------------------------------+ 1837 | G.LSP ID | 1838 +-------------------------------+ +-------------------------------+ 1839 | G.LSP ID | | Explicit route | 1840 +-------------------------------+ +-------------------------------+ 1841 | Contract ID (optional) | | Carrier ID (optional) | 1842 +-------------------------------+ +-------------------------------+ 1843 | Bandwidth-Framing (optional) | | Bandwidth-Framing (optional) | 1844 +-------------------------------+ +-------------------------------+ 1845 | SDH/SONET Options (optional) | | SDH/SONET Options (optional) | 1846 +-------------------------------+ +-------------------------------+ 1847 | Optical (optional) | | Optical (optional) | 1848 +-------------------------------+ +-------------------------------+ 1849 | Directionality (optional) | | Directionality (optional) | 1850 +-------------------------------+ +-------------------------------+ 1851 | Max Signaling Delay (optional)| | Max Signaling Delay (optional)| 1852 +-------------------------------+ +-------------------------------+ 1853 | Priority-Preemption (optional)| | Priority-Preemption (optional)| 1854 +-------------------------------+ +-------------------------------+ 1855 | Network Protection (optional) | | Network Protection (optional) | 1856 +-------------------------------+ +-------------------------------+ 1857 | Side Protection (optional) | | Side Protection (optional) | 1858 +-------------------------------+ +-------------------------------+ 1859 | Diversity (optional) | | Diversity (optional) | 1860 +-------------------------------+ +-------------------------------+ 1861 | Service-related (optional) | | Service-related (optional) | 1862 +-------------------------------+ +-------------------------------+ 1864 Figure 8: G.LSP Modify request 1866 Depending on the modification request the explicit route field can 1867 take different values. For instance, if the modification request 1868 only concerns the source-side protection, then the explicit route 1869 field remains empty. However, if the modification request implies to 1870 change the priority of the G.LSP along the whole path then the 1871 explicit route field is the same as the one calculated during the 1872 G.LSP create request by the CSPF algorithm. In this case, the 1873 explicit route field is defined by the G.LSP identifier since the 1874 intermediate ONEs keep track of the route established for the 1875 corresponding G.LSP. 1877 Note: there are some cases where the framing-bandwidth value of a 1878 G.LSP can not be changed. These exceptions are TBD. 1880 1. Intra-Domain - G.LSP Modification Procedure 1882 The G.LSP Modification procedure and other related mechanism are 1883 TBD. 1885 Papadimitriou et al. Expires May 2001 36 1886 2. Inter-Domain - G.LSP Modification Procedure 1888 The G.LSP modification procedure should include the following steps: 1889 - Since the modify message may be sent over IrDI-NNI interfaces 1890 (meaning through separate administrative authority and thus between 1891 optical networks) some admission control should be provided at the 1892 boundary ONE to control the identity (by means of the Carrier ID) of 1893 the requestor 1895 The G.LSP Modification procedure and other related mechanism are 1896 TBD. 1898 7.5.3.2 G.LSP modify response 1900 The G.LSP modify response is directed from the destination UNI-C to 1901 the source UNI-C through the following sequence: 1902 - UNI: Destination UNI-C -> UNI-N 1903 - NNI: Destination IaDI-NNI -> _ -> Intermediate IaDI-NNI 1904 - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI 1905 - NNI: Intermediate IaDI-NNI -> _ -> Source IaDI-NNI 1906 - UNI: UNI-N -> Source UNI-C 1908 The following figure describes the G.LSP modify response message 1909 sent by the terminating UNI-C to the UNI-N and the corresponding 1910 message sent by the terminating IaDI-NNI after the treatment 1911 performed on this message: 1913 +-------------------------------+ +-------------------------------+ 1914 | G.LSP ID | | G.LSP ID | 1915 +-------------------------------+ +-------------------------------+ 1916 | Result Code | | Result Code | 1917 +-------------------------------+ +-------------------------------+ 1918 | Bandwidth-Framing (optional) | | Bandwidth-Framing (optional) | 1919 +-------------------------------+ +-------------------------------+ 1920 | SDH/SONET (optional) | | SDH/SONET (optional) | 1921 +-------------------------------+ +-------------------------------+ 1922 | Optical (optional) | | Optical (optional) | 1923 +-------------------------------+ +-------------------------------+ 1924 | Directionality (optional) | | Directionality (optional) | 1925 +-------------------------------+ +-------------------------------+ 1926 | Max Signaling Delay (optional)| | Max Signaling Delay (optional)| 1927 +-------------------------------+ +-------------------------------+ 1928 | Priority-Preemption (optional)| | Priority-Preemption (optional)| 1929 +-------------------------------+ +-------------------------------+ 1930 | Network Protection (optional) | | Network Protection (optional) | 1931 +-------------------------------+ +-------------------------------+ 1932 | Side Protection (optional) | | Side Protection (optional) | 1933 +-------------------------------+ +-------------------------------+ 1934 | Diversity (optional) | | Diversity (optional) | 1935 +-------------------------------+ +-------------------------------+ 1936 | Service-related (optional) | | Service-related (optional) | 1938 Papadimitriou et al. Expires May 2001 37 1939 +-------------------------------+ +-------------------------------+ 1941 Figure 9: G.LSP Modify response 1943 The G.LSP modify request could also be generated by an IaDI-NNI 1944 during the creation (or recovery) of a high-priority G.LSP 1945 requesting some of the resources used by the low-priority G.LSP. 1946 This case is analyzed is the next section of this proposal. 1948 7.5.4 G.LSP Status 1950 The G.LSP status message includes the G.LSP status request and 1951 response message. 1953 7.5.4.1 Initiating UNI-C 1955 When initiated by the UNI-C, the G.LSP status query process includes 1956 the G.LSP status request: 1957 - UNI: Source UNI-C -> UNI-N) 1958 - Optionally NNI: Source IaDI-NNI -> _ -> IaDI-NNI) 1959 - Optionally NNI: IaDI-NNI -> _ -> Destination IaDI-NNI) 1961 The G.LSP status response could be the following sequence of 1962 messages: 1963 - Optionally NNI: Destination IaDI-NNI -> _ -> IaDI-NNI) 1964 - Optionally NNI: IaDI-NNI -> _ -> Destination IaDI-NNI) 1965 - UNI: UNI-N -> Destination UNI-C) 1967 7.5.4.2 Initiating UNI-N 1969 This case is not covered by the NNI Specification. 1971 7.5.4.3 Initiating IaDI-NNI 1973 This case is considered to provide the ability for an IaDI-NNI 1974 interface to request about the status of an established G.LSP 1975 passing through the corresponding internal ONE. 1977 Two directions are possible, either to the source UNI-C: 1978 - NNI: G.LSP Status Request (IaDI-NNI -> _ -> Source IaDI-NNI) 1979 - UNI: G.LSP Status Request (UNI-N -> Source UNI-C) 1980 - UNI: G.LSP Status Response (Source UNI-C -> UNI-N) 1981 - NNI: G.LSP Status Response (Source IaDI-NNI -> _ -> IaDI-NNI) 1983 or to the destination UNI-C: 1984 - NNI: G.LSP Status Request (IaDI-NNI -> _ -> Destination IaDI-NNI) 1985 - UNI: G.LSP Status Request (UNI-N -> Destination UNI-C) 1986 - UNI: G.LSP Status Response (Destination UNI-C -> UNI-N) 1987 - NNI: G.LSP Status Response (Destination IaDI-NNI -> _ -> IaDI-NNI) 1989 Since the status request message may be sent over IrDI-NNI 1990 interfaces (meaning through separate administrative authority and 1992 Papadimitriou et al. Expires May 2001 38 1993 thus between optical networks) some CAC control should be provided 1994 at the boundary ONE to control the identity (by means of the Carrier 1995 ID) of the requestor. 1997 4. Initiating IrDI-NNI 1999 This case is considered to provide the ability for an IrDI-NNI 2000 interface to request about the status of an established G.LSP 2001 passing through the corresponding boundary ONE. 2003 Two directions are possible, either to the source UNI-C: 2004 - NNI: G.LSP Status Request (IrDI-NNI -> _ -> Source IaDI-NNI) 2005 - UNI: G.LSP Status Request (UNI-N -> Source UNI-C) 2006 - UNI: G.LSP Status Response (Source UNI-C -> UNI-N) 2007 - NNI: G.LSP Status Response (Source IaDI-NNI -> _ -> IrDI-NNI) 2009 or to the destination UNI-C: 2010 - NNI: G.LSP Status Request (IrDI-NNI -> _ -> Destination IaDI-NNI) 2011 - UNI: G.LSP Status Request (UNI-N -> Destination UNI-C) 2012 - UNI: G.LSP Status Response (Destination UNI-C -> UNI-N) 2013 - NNI: G.LSP Status Response (Destination IaDI-NNI -> _ -> IrDI-NNI) 2015 7.5.5 Notifications 2017 The IaDI-NNI interface may send a G.LSP notification message to 2018 notify the source and/or destination UNI-C about the current status 2019 of a G.LSP. This G.LSP notification message has to be considered has 2020 an unsolicited message. 2022 The notification messages could follow one of these sequences: 2023 - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI) 2024 - NNI: Intermediate IaDI-NNI -> _ -> Destination IaDI-NNI) 2025 - UNI: UNI-N -> Destination UNI-C 2027 - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI 2028 - NNI: Intermediate IaDI-NNI -> _ -> Source IaDI-NNI 2029 - UNI: UNI-N -> Source UNI-C 2031 7.6 Constraint-based Routing 2033 The section describes the concepts of Explicit route and Record 2034 route. In order to introduce these concepts, we first describe the 2035 mechanisms to establish bi-directional G.LSPs. 2037 7.6.1 Bi-directional G.LSP setup 2039 The assumption made throughout this proposal is that G.LSP are 2040 optical paths or TDM circuits whose setup is bi-directional (even if 2041 we consider that a bi-directional path results from the merge of two 2042 unidirectional paths). However, G.LSPs are fundamentally 2043 unidirectional and point-to-point logical-link connections. 2045 Papadimitriou et al. Expires May 2001 39 2046 A simple solution can be proposed to avoid racing condition for bi- 2047 directional G.LSP setup. As proposed by [CRLDP-OPT], the solution 2048 suggests forming a master and slave relationship between two 2049 adjacent ONEs. The ONE with the higher ONE Ipv4 address is the 2050 master to the other. It is always the master ONE that makes logical- 2051 port assignment for both itself and its slave peer. 2053 Since the ONE Ipv4 address is a static information, we propose to 2054 enhance this mechanism, and use the previous mechanism as the 2055 initial step. After, when a G.LSP is created for another user-group 2056 the priority is given to the slave of the previous step. Hence, the 2057 master-slave relationship is defined per user-group. 2059 7.6.2 Explicit Route 2061 In the distributed model, the explicit route is calculated through 2062 the CSPF algorithm at the source of the G.LSP within the optical 2063 network. The source ONE can be a boundary ONE, an area border ONE or 2064 an autonomous-system boundary ONE. In the last two cases the source 2065 ONE is referred as a source intermediate ONE. 2067 In the centralized model, the explicit route is calculated through 2068 the CSPF algorithm at the Network Management System. In this case, 2069 the NMS informs the G.LSP source ONE about the nodes to include in 2070 the path that it will request through the optical network. 2072 The value of the explicit route is a variable-size list including 2073 three types of fields: 2074 - Internal-point ID 2075 - Node ID (i.e. the Ipv4 address of the ONE) 2076 - Autonomous System ID which is the identifier of a set of ONEs 2077 having a single routing policy running under a single administrative 2078 authority. 2080 Note: Internal-point ID is considered here as a `heuristic' to avoid 2081 to specify the mechanism through which the input and output logical- 2082 port ID of the G.LSP `link' are determined between neighboring ONE 2083 during the G.LSP setup process. 2085 These values are case specific: 2086 - The internal-point ID is the sub-field used to identify the next- 2087 hop ONE during the G.LSP setup process 2088 - The node ID is the sub-field used to identify a subsequent hop 2089 within the same area or same autonomous-system (within the same IGP 2090 technical administration domain) 2091 - The autonomous-system ID (which corresponds to the autonomous- 2092 system number) is the sub-field used to identify a subsequent 2093 hierarchical level included within the explicit route calculated for 2094 the G.LSP. 2096 Example 1: 2098 Papadimitriou et al. Expires May 2001 40 2099 If the explicit route corresponds to the following hop sequence: 2101 Source ONE [0] > Internal ONE [1] > Internal ONE [2] > Internal ONE 2102 [i] > _ > Internal ONE [N-1] > Destination ONE [N] 2104 represented by the following sequence of identifiers which 2105 corresponds to explicit route at the initial source point: 2107 Source Termination-Point ID [0] > Internal-point ID [1] > Node ID 2108 [2] > _ > Node ID [i] > _ > Node ID [N-1] > Destination Termination- 2109 point [N] 2111 1. Then, at the first hop, the explicit route is the following: 2113 Internal-point ID [1] > Internal-point ID [2] > _ > Node ID [i] > _ 2114 > Node ID [N-1] > Destination Termination-point [N] 2116 2. At the second hop, the explicit route is the following: 2118 Internal-point ID [2] > Internal-point ID [3] > _ > Node ID [i] > _ 2119 > Node ID [N-1] _ Destination Termination-point [N] 2121 3. At the hop i, the explicit route is the following: 2123 Internal-point ID [i] > Internal-point ID [I+1] > _ > Node ID [N-1] 2124 > Destination Termination-point [N] 2126 4. At the last hop, the explicit route is the following: 2128 Destination Termination-point [N] 2130 Example 2: 2132 If the explicit route corresponds to the following hop sequence: 2134 Source ONE [0] > Internal ONE [1] > Internal ONE [2] > _ > Internal 2135 ONE [i] > _ > Internal ONE [N-1] > Destination ONE [N] 2137 represented by the following sequence of identifiers which 2138 corresponds to explicit route at the initial source point: 2140 Source Termination-Point ID [0] > Internal-point ID [1] > Node ID 2141 [2] _ > Node ID [i] > _ > Node ID [I+M] > Destination Termination- 2142 point [N] 2144 where the Node ID [I+M] corresponds to an area border ONE (I + M < 2145 N) 2147 1. Then, at the first hop, the explicit route is the following: 2149 Internal-point ID [1] > Internal-point ID [2] > _ > Node ID [i] > _ 2150 > Node ID [I+M] > Destination Termination-point [N] 2152 Papadimitriou et al. Expires May 2001 41 2153 2. At the second hop, the explicit route is the following: 2155 Internal-point ID [2] > Internal-point ID [3] > _ > Node ID [i] > _ 2156 > Node ID [I+M] > Destination Termination-point [N] 2158 3. At the hop i, the explicit route is the following: 2160 Internal-point ID [i] > Internal-point ID [I+1] > _ > Node ID [I+M] 2161 > Destination Termination-point [N] 2163 4. At the hop I+M, the explicit route is the following: 2165 Internal-point ID [I+M] > Internal-point ID [I+M+1] > _ > Node ID 2166 [N-1] > Destination Termination-point ID [N] 2168 Where the Internal-point ID [I+M] is the internal-point of the ONE 2169 located at the border of the area and directed to the outgoing area 2170 and the Internal-point ID [I+M+1] is the internal-point of the 2171 internal ONE located within the incoming area. 2173 So the area border ONE calculate the explicit route to the 2174 destination termination-point ID by executing the C-SPF algorithm 2175 and inserts a number of hops within the explicit route field in 2176 order to reach the destination termination-point ID of the requested 2177 G.LSP. 2179 Example 3: 2181 If the explicit route corresponds to the following hop sequence: 2183 Source ONE [0] > Internal ONE [1] > Internal ONE [2] > _ > Internal 2184 ONE [i] > _ > Autonomous-System [N-1] > Destination ONE [N] 2186 represented by the following sequence of identifiers which 2187 corresponds to explicit route at the initial source point: 2189 Source Termination-Point ID [0] > Internal-point ID [1] > Node ID 2190 [2] > _ > Node ID [i] > _ > AS ID [N-1] > Destination Termination- 2191 point [N] 2193 Then, at the first hop, the explicit route is the following: 2195 Internal-point ID [1] > Internal-point ID [2] > _ > Node ID [i] > _ 2196 > AS ID [N-1] > Destination Termination-point [N] 2198 At the hop i, the explicit route is the following: 2200 Internal-point ID [i] > Internal-point ID [I+1] > _ > AS ID [N-1] > 2201 Destination Termination-point [N] 2203 At the hop N-2, the explicit route is the following: 2205 Papadimitriou et al. Expires May 2001 42 2206 Internal-point ID [N-2] > Internal-point ID [N-1] > Destination 2207 Termination-point ID [N] 2209 Where the Internal-point ID [N-2] is the internal-point of the ONE 2210 located at the boundary of the outgoing AS and the Internal-point ID 2211 [N-1] is the internal-point of the ONE located at the boundary of 2212 the incoming AS. 2214 So the outgoing boundary ONE selects the internal-point of the next 2215 hop and replaces the AS ID by the corresponding internal-point ID. 2216 Now the boundary ONE of the incoming AS has to calculate the 2217 explicit route to the destination termination-point ID by executing 2218 the CSPF algorithm. 2220 Consequently a number of hops are inserted within the explicit route 2221 field in order to reach the destination termination-point ID of the 2222 requested G.LSP. 2224 7.6.3 Record route 2226 In order to improve the reliability and the manageability of the 2227 G.LSP being established we optionally introduce the concept of the 2228 route-record of lightpath of the G.LSP being established. 2230 The record-route is an empty field at the source ONE and to capture 2231 the precise route of the path being set up with port level 2232 information. This is done by the following procedure: at each 2233 intermediate ONE, the NNI inserts its node ID and both the output 2234 logical-port ID and the input logical-port ID selected for the path 2235 in the G.LSP create request message. The ligthpath create request 2236 message received by the destination ONE and the G.LSP create 2237 response message received by the source ONE will have the complete 2238 route followed by the established G.LSP at the logical-port ID 2239 level. 2241 Example 1: 2243 If the explicit route corresponds to the following hop sequence: 2245 Source ONE [0] > Internal ONE [1] > Internal ONE [2] > _ > 2246 Internal ONE [i] > _ > Internal ONE [N-1] > Destination ONE [N] 2248 represented by the following sequence of identifiers which 2249 corresponds to explicit route at the initial source point: 2251 Explicit Route = Source Termination-Point ID [0] > Internal-point ID 2252 [1] _ Node ID [2] > _ > Node ID [i] > _ > Node ID [N-1] > 2253 Destination Termination-point [N] 2255 Record Route = Source Termination-Point ID [0] 2257 Papadimitriou et al. Expires May 2001 43 2258 1. Then, at the first hop, the explicit and record routes are the 2259 following: 2261 Explicit Route = Internal-point ID [1] > Internal-point ID [2] > _ > 2262 Node ID [i] > _ > Node ID [N-1] > Destination Termination-point [N] 2264 Record Route = Source Termination-Point ID [0] > Internal-point ID 2265 [1] 2267 2. At the second hop, the explicit and record routes are the 2268 following: 2270 Explicit Route = Internal-point ID [2] > Internal-point ID [3] > _ > 2271 Node ID [i] > _ > Node ID [N-1] > Destination Termination-point [N] 2273 Record Route = Source Termination-Point ID [0] > Internal-point ID 2274 [1] > Internal-point ID [2] 2276 3. At the hop i, the explicit are record routes are the following: 2278 Explicit Route = Internal-point ID [i] > Internal-point ID [I+1] > _ 2279 > Node ID [N-1] > Destination Termination-point [N] 2281 Record Route = Source Termination-Point ID [0] > Internal-point ID 2282 [1] > Internal-point ID [2] > _ > Internal-point ID [i] 2284 4. At the last hop, the explicit and record routes are the 2285 following: 2287 Explicit Route = Destination Termination-point [N] 2289 Record Route = Source Termination-Point ID [0] > Internal-point ID 2290 [1] _ Node ID [2] > _ > Node ID [i] > _ > Node ID [N-1] > 2291 Destination Termination-point [N] 2293 In the transmit direction the internal-point ID are the input 2294 internal-point ids. In the reverse direction, the record-route 2295 included within the G.LSP create response message each intermediate 2296 ONE inserts the input internal-point id which corresponds to the 2297 output internal-point id of the transmit direction. 2299 7.7 Extended NNI Signaling Services 2301 The extended NNI signaling services include the following processes: 2302 - Resource Reservation mechanisms 2303 - Protection mechanisms 2304 - Preemption mechanisms 2306 These mechanisms are related to the priority level and value 2307 associated to the G.LSPs. The priority value is included within the 2308 client G.LSP create request. 2310 Papadimitriou et al. Expires May 2001 44 2311 7.7.1 Framing-Bandwidth - Priority 2313 The G.LSP create request message includes the desired framing and 2314 bandwidth requested by the client. 2316 Each of the source, intermediate and destination ONE included within 2317 the explicit route field has a local ONE database including for each 2318 of its logical-ports: 2319 - the available bandwidth (AB) 2320 - the minimum and maximum reservable bandwidth (MinRB and MaxRB) 2321 - the associated priority (AB[p], MinRB[p] and MaxRB[p]) 2323 The priority value is the lowest priority at which this bandwidth is 2324 available. So, the logical-point resource information is represented 2325 by the following entries into the local ONE database: 2327 Local ONE Neighbor ONE 1 State 2328 -------------------------------------------------------------------- 2329 LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active 2330 LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active 2332 Local ONE Neighbor ONE 2 State 2333 -------------------------------------------------------------------- 2334 LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active 2335 LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active 2337 When the source ONE receives a G.LSP create request, and the CSPF 2338 has established the corresponding path (i.e., explicit route) into 2339 the optical sub-network, the following sequence occurs: 2340 - the source ONE waits until receiving the G.LSP create response 2341 message to update the local database (and subsequently flood the ONE 2342 updates throughout the optical sub-network) 2343 - the source ONE marks the `planned' reserved bandwidth as reserved 2344 so that no other G.LSP create request can use it. 2346 Consequently, we define four states for the framing-bandwidth 2347 parameter within the local ONE database: 2348 - Unused: FB not in use, can be reserved to establish a G.LSP 2349 - Reserved: the corresponding ONE is wanting for a G.LSP create 2350 request before marking the corresponding value as used 2351 - Used: FB in use, the only way to use this resource is through the 2352 preemption mechanism see below 2353 - Reservable: the corresponding ONE is waiting for the G.LSP delete 2354 response before marking the corresponding value as unused 2356 State Diagram: State Diagram is TDB 2358 For instance, if the G.LSP is requested with 1 units of bandwidth 2359 and with priority r then the local database is updated as follows 2360 after the G.LSP create request message has been forwarded to the 2361 next hop: 2363 Papadimitriou et al. Expires May 2001 45 2364 Local ONE Status G.LSP 2365 -------------------------------------------------------------------- 2366 LP-ID Reserved Bandwidth [p] Used G.LSP ID 1 2367 LP-ID Available Bandwidth [q] Unused G.LSP ID 2 2368 LP-ID Reserved Bandwidth [r] Reserved G.LSP ID 3 2369 LP-ID Reserved Bandwidth [s] Used G.LSP ID 4 2371 After the G.LSP create response message has been forwarded to the 2372 next hop, the local database is updated as follows: 2374 Local ONE Status G.LSP 2375 -------------------------------------------------------------------- 2376 LP-ID Reserved Bandwidth [p] Used G.LSP ID 1 2377 LP-ID Available Bandwidth [q] Unused G.LSP ID 2 2378 LP-ID Reserved Bandwidth [r] Used G.LSP ID 3 2379 LP-ID Reserved Bandwidth [s] Used G.LSP ID 4 2381 7.7.2 Protection - Priority 2383 Mechanisms TBD. 2385 7.7.3 Preemption mechanisms 2387 The preemption mechanisms are related to the pre-emptability of the 2388 G.LSP during G.LSP creation process (setup preemption) or during the 2389 application of the G.LSP protection (recovery preemption). The 2390 applicability of the proposed mechanism is still under study. 2392 1. Setup Preemption 2394 If the G.LSP create requests with 1 unit of bandwidth and with 2395 priority p (p > q > r > s > t) and there is no more available 2396 bandwidth as indicated within the local ONE database: 2398 Local ONE Status G.LSP 2399 -------------------------------------------------------------------- 2400 LP-ID Reserved Bandwidth [q] Used G.LSP ID 1 2401 LP-ID Reserved Bandwidth [r] Used G.LSP ID 2 2402 LP-ID Reserved Bandwidth [s] Used G.LSP ID 3 2403 LP-ID Reserved Bandwidth [t] Used G.LSP ID 4 2405 Then the reserved bandwidth for G.LSP 4 is preempted and marked as 2406 reserved for this new G.LSP request; the local database is updated 2407 as follows after the G.LSP create request message has been forwarded 2408 to the next hop: 2410 Local ONE Status G.LSP 2411 -------------------------------------------------------------------- 2412 LP-ID Reserved Bandwidth [q] Used G.LSP ID 1 2413 LP-ID Reserved Bandwidth [r] Used G.LSP ID 2 2414 LP-ID Reserved Bandwidth [s] Used G.LSP ID 3 2416 Papadimitriou et al. Expires May 2001 46 2417 LP-ID Reserved Bandwidth [p] Reserved G.LSP ID 5 2419 After the G.LSP create response message has been forwarded to the 2420 next hop, the local database is updated as follows: 2422 Local ONE Status G.LSP 2423 -------------------------------------------------------------------- 2424 LP-ID Reserved Bandwidth [q] Used G.LSP ID 1 2425 LP-ID Reserved Bandwidth [r] Used G.LSP ID 2 2426 LP-ID Reserved Bandwidth [s] Used G.LSP ID 3 2427 LP-ID Reserved Bandwidth [p] Used G.LSP ID 5 2429 The lower priority G.LSP preemption generates as notification 2430 message to the corresponding source ONE and destination ONE which in 2431 turn forward a notification message to the corresponding source and 2432 destination clients. 2434 State Diagram: State Diagram is TDB 2436 2. Recovery Preemption 2438 The same procedure and mechanisms as described in the previous 2439 subsection are applicable but in this case the preemption decision 2440 is related to unavailable bandwidth during G.LSP recovery. In this 2441 case, G.LSP of higher holding priority will take the precedence over 2442 G.LSP of lower priority. 2444 This recovery preemption mechanism is applied link-by-link and 2445 consequently can be applied from the source ONE to the destination 2446 ONE. This means that since the holding priority of a given ligthpath 2447 is the same on each the intermediate through which this G.LSP has 2448 been established the only way to not recover a higher priority G.LSP 2449 could only be related to a local decision. However, for an optical 2450 network, which does not oversubscribe the number of established 2451 high-priority G.LSP this situation should not occur. 2453 State Diagram: State Diagram is TDB 2455 8. Hierarchical Network Model 2457 The hierarchical routing model considered here is based on the OSPF- 2458 Like protocol version whose requirements have been detailed in the 2459 previous sections of this document and the eBGP protocol. Extensions 2460 of the eBGP protocol are TBD. 2462 The first model considers the optical sub-network as corresponding 2463 to an OSPF area (distinction is made on the NNI interface type): 2464 - The IrDI-NNI interfaces are defined as Trusted NNI interfaces and 2465 they are running OSPF. In this case, IrDI-NNI interface is the 2466 interface between the backbone area0 and the areas surrounding the 2467 area0 2469 Papadimitriou et al. Expires May 2001 47 2470 - The IaDI-NNI interfaces are defined as Trusted NNI interfaces and 2471 they are running OSPF. In this case, the IaDI-NNI interface is 2472 considered as the interface between internal ONE or between an 2473 internal and a boundary ONE belonging to the same area. 2475 The second model considers the optical sub-network as corresponding 2476 to an OSPF Autonomous System (distinction is made on the NNI 2477 interface type and on the NNI interface privacy): 2478 - The IaDI-NNI interfaces are defined as Trusted NNI interfaces and 2479 they are running OSPF. In this case, the IaDI-NNI interface is 2480 considered as the interface between internal ONE or between an 2481 internal and a boundary ONE belonging to the same Autonomous System. 2482 - The IrDI-NNI interfaces are defined as Untrusted NNI interfaces 2483 and they are running eBGP. In this case, the IrDI-NNI interface is 2484 considered as the interface between the OSPF Autonomous System and 2485 the external network. The corresponding ONE can be defined as an 2486 Autonomous System optical entity. 2488 The proposed model can be combined to form a hierarchical optical 2489 network: 2490 By combining both models, we obtain the following model: 2491 - The IaDI-NNI interfaces are defined as Trusted NNI interfaces 2492 running OSPF protocol 2493 - The IaDI-NNI or IrDI-NNI interfaces are defined as Trusted NNI 2494 interfaces running OSPF protocol 2495 - The IrDI-NNI interfaces are defined as Untrusted NNI interfaces 2496 running eBGP protocol 2498 The eBGP protocol is running on sub-network boundary ONEs (which 2499 from the OSPF point-of-view can be considered as an ASBR). The model 2500 provides the capacity to connect several OSPF Autonomous Systems 2501 together through eBGP protocol. 2503 The hierarchical optical network model is represented by the 2504 following figure: 2506 +------------------------------------------------------------------+ 2507 | OSPF Autonomous System 10 | 2508 | +-------------+ | 2509 | |Boundary ONE1| IaDI-NNI | 2510 | |OSPF Area 10 |-- | 2511 | +-------------+ | +-------------+ IaDI-NNI +-------------+ | 2512 | ------|Internal ONE4|----------|Internal ONE6| | 2513 | +-------------+ ------|OSPF Area 0 |----------|OSPF Area 30 | | 2514 | |Boundary ONE2| | +-------------+ +-------------+ | 2515 | |OSPF Area 10 |-- |IaDI-NNI | 2516 | +-------------+ IaDI-NNI | | 2517 | | | 2518 | | | 2519 | |IaDI-NNI | 2520 | +-------------+ +-------------+ IaDI-NNI +-------------+ | 2521 | |Boundary ONE3|---------|Internal ONE5|----------|Internal ONE7| | 2523 Papadimitriou et al. Expires May 2001 48 2524 | |OSPF Area 20 |---------|OSPF Area 0 |----------|OSPF Area 40 | | 2525 | +-------------+IaDI-NNI +-------------+ +-------------+ | 2526 | IrDI- | |IrDI- | 2527 | NNI | |NN | 2528 +--------|------------------------------------------------|--------+ 2529 | | 2530 | | 2531 +--------|------------------------------------------------|--------+ 2532 | IrDI- | BGP Transit |IrDI- | 2533 | NNI | Area |NN | 2534 | +-------------+ +-------------+ +-------------+ | 2535 | |Boundary ONE1|---------|Internal ONE2|----------|Boundary ONE3| | 2536 | |OSPF Area 0 |---------|OSPF Area 0 |----------|OSPF Area 0 | | 2537 | +-------------+IaDI-NNI +-------------+ IaDI-NNI +-------------+ | 2538 | | | | | 2539 | +-------------+ +-------------+ +-------------+ | 2540 | |Boundary ONE3|---------|Internal ONE5|----------|Boundary ONE7| | 2541 | |OSPF Area 0 |---------|OSPF Area 0 |----------|OSPF Area 0 | | 2542 | +-------------+IaDI-NNI +-------------+ IaDI-NNI +-------------+ | 2543 | IrDI- | |IrDI- | 2544 | NNI | |NN | 2545 +--------|------------------------------------------------|--------+ 2546 | | 2547 | | 2548 +--------|----------+ +----------|--------+ 2549 | IrDI- | | | |IrDI- | 2550 | NNI | | | |NN | 2551 | +-------------+ | | +-------------+ | 2552 | |Boundary ONE1| | | |Boundary ONE1| | 2553 | |OSPF Area 10 | | | |OSPF Area 10 | | 2554 | +-------------+ | | +-------------+ | 2555 | | | | | | 2556 | +-------------+ | | +-------------+ | 2557 | |Boundary ONE2| | | |Boundary ONE2| | 2558 | |OSPF Area 10 | | | |OSPF Area 10 | | 2559 | +-------------+ | | +-------------+ | 2560 | BGP AS-10 | | BGP AS-20 | 2561 +-------------------+ +-------------------+ 2563 Figure 10: Hierarchical optical network model 2565 - IaDI-NNI interfaces are running OSPF-Lite protocol (note IaDI-NNI 2566 interfaces could be untrusted or trusted, however, in most cases 2567 IaDI-NNI interfaces are defined as trusted NNI interfaces) 2569 - IrDI-NNI Untrusted interfaces are running eBGP extended protocol 2571 Since the OSPF version considered in this section refers to OSPF- 2572 Lite whose requirements have been detailed in the section 6, some 2573 extensions need to be considered in order to: 2574 - generate ONE advertisements at Autonomous System boundary ONEs 2575 (these ONE advertisements are internal summary advertisements) 2577 Papadimitriou et al. Expires May 2001 49 2578 - generate ONE advertisements at Area boundary ONEs (these ONE 2579 advertisements are external summary advertisements) 2581 9. Security Considerations 2583 Security considerations have been briefly described within the 2584 Section 4 where we describe the security of the signaling control 2585 plane. Other security considerations are for further study. 2587 10. References 2589 1. [CRLDP-OPT] B. Tang et al., `Extensions to CR-LDP for Path 2590 Establishment in Optical Networks', Internet Draft, draft-tang- 2591 crldp-optical-00.txt, September 2000. 2593 2. [ENH-LSPS] D.Papadimitriou et al., `Enhanced LSP Services', 2594 Internet Draft, draft-papadimitriou-enhanced-lsps-01.txt, 2595 November 2000. 2597 3. [GMPLS] P. Ashwood-Smith et al., `Generalized MPLS: Signaling 2598 Functional Description', Internet Draft, draft-ietf-mpls- 2599 generalized-signaling-00.txt, October 2000. 2601 4. [MPLS-LMP] J. Lang et al., `Link Management Protocol', Internet 2602 Draft, draft-lang-mpls-lmp-01.txt, January 2001. 2604 5. [MPLS-OUNI] B. Rajagopalan et al., `Signaling Requirements at 2605 the Optical UNI', Internet Draft, draft-bala-mpls-optical-uni- 2606 signaling-00.txt, July 2000. 2608 6. [MPLS-TE] S.Venkatachalam et al., `A Framework for the LSP Setup 2609 Across IGP Areas for MPLS Traffic Engineering', Internet Draft, 2610 draft-venkatachalam-interarea-mpls-te-01.txt, October 2000. 2612 7. [OIF2000.125.2] B. Rajagopalan et al., `User Network Interface 2613 v1.0 Proposal', OIF Contribution 125.2, October 2000. 2615 8. [OIF2000.200] D. Pendarakis et al., `Signaling Transport 2616 Mechanisms for UNI 1.0', OIF Contribution 200, September 2000. 2618 9. [OIF2000.261.1] D. Papadimitriou et al., `Address Registration 2619 and Resolution', OIF Contribution 261, November 2000. 2621 10. [RFC 1662] W. Simpson et al., `PPP in HDLC-like Framing', 2622 Internet RFC 1662, July 1994. 2624 11. [RFC 2615] A. Malis et al., `PPP over SONET/SDH', Internet RFC 2625 2615, June 1999. 2627 11. Acknowledgments 2629 Papadimitriou et al. Expires May 2001 50 2630 The authors would like to thank Bernard Sales, Emmanuel Desmet, Hans 2631 De Neve, Fabrice Poppe and Jim Jones for their constructive 2632 comments. 2634 12. Author's Addresses 2636 Dimitri Papadimitriou 2637 Alcatel NSG-NA 2638 F. Wellesplein 3, B-2018 Antwerpen, Belgium 2639 Phone: 32 3 2408491 2640 Email: dimitri.papadimitriou@alcatel.be 2642 Michele Fontana 2643 Alcatel TND 2644 Via Trento 30, I-20059 Vimercate, Italy 2645 Phone: 39 039 6867053 2646 Email: Michele.Fontana@netit.alcatel.it 2648 Gert Grammel 2649 Alcatel Optics 2650 Via Trento 30, I-20059 Vimercate, Italy 2651 Phone: +39 039 686-4453 2652 Email: Gert.Grammel@netit.alcatel.it 2654 Yangguang Xu 2655 Lucent Technologies, Inc. 2656 21-2A41, 1600 Osgood Street, North Andover, MA 01845 2657 Phone: 1 978 4572345 2658 Email: xuyg@lucent.com 2660 Zhi-Wei Lin 2661 Lucent Technologies, Inc. 2662 101 Crawfords Corner Rd, Rm 3C-512, NJ 07733-3030 2663 Phone: 1 732 9495141 2664 Email: zwlin@lucent.com 2666 Sivakumar Sankaranarayanan 2667 Lucent Technologies, Inc. 2668 101 Crawfords Corner Rd, Rm 3C-512, NJ 07733-3030 2669 Phone: 1 732 9495578 2670 Email: ssnarayanan@lucent.com 2672 Papadimitriou et al. Expires May 2001 51 2673 Raj Jain 2674 Nayna Networks 2675 157 Topaz St., Milpitas, CA 95035, USA 2676 Phone: 408-956-8000X309 2677 Email: raj@nayna.com 2679 Yang Cao 2680 Sycamore Networks 2681 150 Apollo Drive, Chelmsford, MA 01824 2682 Phone: 1 978-367-2518 2683 Email: Yang.Cao@sycamorenet.com 2685 Yong Xue 2686 UUNET/WorlCom 2687 22001 Loudoun County Parkway, Ashburn, VA 20148 2688 Phone: 1 703 8865358 2689 Email: yxue@uu.net 2691 Papadimitriou et al. Expires May 2001 52 2692 Full Copyright Statement 2694 "Copyright (C) The Internet Society (date). All Rights Reserved. 2695 This document and translations of it may be copied and furnished to 2696 others, and derivative works that comment on or otherwise explain it 2697 or assist in its implementation may be prepared, copied, published 2698 and distributed, in whole or in part, without restriction of any 2699 kind, provided that the above copyright notice and this paragraph 2700 are included on all such copies and derivative works. However, this 2701 document itself may not be modified in any way, such as by removing 2702 the copyright notice or references to the Internet Society or other 2703 Internet organizations, except as needed for the purpose of 2704 developing Internet standards in which case the procedures for 2705 copyrights defined in the Internet Standards process must be 2706 followed, or as required to translate it into 2708 Papadimitriou et al. Expires May 2001 53