idnits 2.17.1 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt: ** The Abstract section seems to be numbered -(646): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 15) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (June 2002) is 7958 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) == Unused Reference: 'GMPLS-ARCH' is defined on line 593, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-02 == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-12 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'GMPLS-ISIS') == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-07 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-08 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-routing-04 == Outdated reference: A later version (-05) exists of draft-douville-ccamp-gmpls-waveband-extensions-01 -- Possible downref: Normative reference to a draft: ref. 'GMPLS-WBEXT' == Outdated reference: A later version (-05) exists of draft-ietf-ipo-impairments-02 ** Downref: Normative reference to an Informational draft: draft-ietf-ipo-impairments (ref. 'IPO-IMP') == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-04 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') -- Possible downref: Normative reference to a draft: ref. 'OKI-IPO' -- Possible downref: Normative reference to a draft: ref. 'OKI-UPSTREAM' -- Possible downref: Normative reference to a draft: ref. 'OZU-FLAGS' -- Possible downref: Non-RFC (?) normative reference: ref. 'ONM-1' == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-06 Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Martin Vigoureux 3 Internet Draft Emmanuel Dotaro 4 Expires: December 2002 Dimitri Papadimitriou 5 Alcatel 7 Eiji Oki 8 Wataru Imajuku 9 Naoaki Yamanaka 10 NTT 12 June 2002 14 GMPLS Architectural Considerations for (Hybrid) Photonic Networks 16 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. Internet-Drafts are draft documents valid for a maximum of 27 six months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet- Drafts 29 as reference material or to cite them other than as "work in 30 progress". 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 1. Abstract 40 Optical networks could have been reduced to point-to-point links but 41 technology evolution led the way to an evolution trend. The concept 42 of optical transparency first took shape through the development of 43 photonic switching fabrics and is now being reinforced by the 44 continuous efforts produced to increase transmission distances. 45 Optical networking obviously can not be left aside of such 46 evolutions and so it is for the (in particular, GMPLS-based) 47 protocols that control these photonic networks. This document 48 highlights the enhancements that seem to be necessary for GMPLS to 49 cover these emerging trends (transparency, hybrid nodes) and fulfil 50 its role of a generalized control plane. 52 Vigoureux et al. December 2002 1 53 2. Summary for Sub-IP Area 55 2.1. Summary 57 See the Abstract above. 59 2.2. Where does it fit in the Picture of the Sub-IP Work 61 This work fits the CCAMP box. 63 2.3. Why is it Targeted at this WG 65 This draft is targeted at the CCAMP WG because it proposes a first 66 input on common signaling and routing protocol considerations 67 in multi-service environments. 69 2.4. Justification of Work 71 The WG should consider this document as it provides an architectural 72 framework for GMPLS-capable multi-service (with shared regeneration) 73 environments, topic that attracts increasing attention over past 74 years from the engineering community. 76 3. Conventions used in this document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC-2119. 82 4. Introduction 84 Optical networks could have been reduced to point-to-point links but 85 technology evolution led the way to an evolution trend. 87 The concept of optical transparency first took shape through the 88 development of photonic switching fabrics and is now being 89 reinforced by the continuous efforts produced to increase 90 transmission distances. Matching these evolutions, are the efforts 91 made at the CCAMP WG for the definition a generalized control plane 92 architecture to encompass the networking issues that arise in such 93 networks. 95 In parallel to the introduction of heterogeneous networks with 96 limited conversion/regeneration functions, optical networks are 97 going beyond the restrictive transport function they first proposed. 98 Nodes are evolving to integrate multiple switching capabilities 99 jointly controlled in order to propose enhanced inter-working, 100 leading to resource utilization optimization. Such multi-level 101 switching architectures can be composed, for example, of a photonic 102 switch fabric topped by an opaque one offering regeneration function 103 and switching at another granularity. These architectures will be 104 referred in this document to as Hybrid Photonic Architectures (HPAs) 106 Vigoureux et al. December 2002 2 107 and the corresponding networks to as Hybrid Photonic Networks 108 (HPNs). 110 Optical networking obviously can not be left aside of such 111 fundamental evolutions and so it is for the (in particular, GMPLS- 112 based) protocols that control these photonic networks. Work ongoing 113 at the IPO working group reflects the need to consider topological 114 as well as physical constraints of photonic networks (see [IPO- 115 IMP]). 117 Unique aspect of hybrid photonic networks 118 ----------------------------------------- 120 In hybrid photonic environments, constraints such as resource 121 availability are of utmost importance where regeneration/conversion 122 functions are limited and shared. In HPNs, resources are no longer 123 symmetrical with respect to regeneration/conversion functions. This 124 feature deeply impacts wavelength selection schemes (i.e. spectral 125 path computation) as well as wavelength continuity that will be 126 harder to achieve. This, in addition to the selection of 127 regeneration points conditioned by resource availability and signal 128 degradation. 130 This document highlights the enhancements that seem to be necessary 131 for GMPLS to cover these emerging trends (transparency, hybrid 132 nodes) and fulfil its role of a generalized control plane. 134 The first part of the document gives an overview of the impact of 135 optical transparency issues on signaling and how can they be 136 addressed. The second part is dedicated to routing considerations 137 while the third focuses on signaling. 139 5. Different Approaches 141 Establishing a connection throughout an optical network is achieved 142 in two steps: determination of an explicit spatial route followed by 143 a signaling phase selecting network resources (e.g. sequence of 144 wavelengths) to be used by the LSP. In this document, these two 145 phases are respectively referred to as spatial routing and spectral 146 routing. 148 The different schemes (see also [ONM-1]) listed below tend to 149 address the issues arising from the introduction of transparency in 150 optical networks. The impact of each scheme on the protocol 151 architecture is detailed afterwards. 153 5.1. First Scheme 155 The ingress node performs spatial and spectral routing decision. 156 Due to link-state scalability issues (and if the spectral routing 157 related information is not fed through the backward signaling flow), 158 this scheme is not considered in the current context. 160 Vigoureux et al. December 2002 3 161 5.2. Second Scheme 163 The ingress node performs spatial routing, while the intermediate 164 nodes perform spectral routing (hop-by-hop label selection is part 165 of spectral routing). 167 As currently specified, the GMPLS protocol suite definition reflects 168 this scheme. Per [GMPLS-SIG], the Label Set selection works 169 according to an AND scheme (see also [OKI-IPO]). Each hop restricts 170 the Label Set sent to the next hop from the one received from the 171 previous hop by performing an AND operation between the wavelength 172 referred by the labels it includes with the one available on the 173 ongoing interface. The constraint to perform this AND operation is 174 up to the node local policy (even if one expects a consistent policy 175 configuration throughout a given transparency domain). 177 When wavelength conversion is performed at an intermediate node, a 178 new Label Set is generated. The egress nodes selects one label in 179 the Label Set received at the node. According to the selected label 180 for the incoming link at the egress node, each label on the route is 181 determined in a hop-by-hop manner. 183 5.3. Third Scheme 185 The ingress node performs spatial routing while the egress node 186 performs spectral routing. Here, intermediate nodes may be allowed 187 performing some local processing. 189 Spectral related information is fed through signaling downward to 190 the egress node according to an ALL scheme (see also [OKI-IPO]). For 191 this purpose, at each hop, a Label Set object/TLV may be appended to 192 the global Label Set (more precisely to the list of Label Set 193 objects defining an end-to-end significant Label Set). Additional 194 processing may be performed at intermediate nodes depending on local 195 constraints. 197 At the end of the process and according to the collected spectral 198 information, the egress node determines all the labels on the route 199 considering the (individual) local constraints. 201 6. Routing Enhancements 203 All the previously listed schemes share the common approach of 204 performing spatial routing at ingress. 206 The computation of the spatial route is done upon information 207 flooded by an IGP such as OSPF or ISIS (see for OSPF [OSPF-TE], and 208 [GMPLS-OSPF] and for IS-IS [ISIS-TE] and [GMPLS-ISIS]). Obviously, 209 the more precise the information is, the more deterministic the 210 result is. However, assumption is made that periodical flooding and 211 link state information processing is not scalable if performed at 212 component link level. This statement might also depend on the 213 frequency of the update. Moreover, maintaining a routing adjacency 215 Vigoureux et al. December 2002 4 216 for each component link seems not realistic also for the same 217 scalability reasons. Therefore, the use of TE Links with stochastic 218 resource selection may be thus retained in this context. 220 Several constraints have already been envisaged to be taken into 221 account for constraint based spatial path computation. Bandwidth 222 availability and switching capability are, for example, information 223 available via TE Link Sub-TLVs (see [GMPLS-RTG]). However, it may be 224 appropriate to complete this information in order to reflect 225 enhanced link characteristics but also hybrid photonic network 226 features. 228 6.1.1. Physical Constraints 230 Due to the limited number of (shared) regeneration capability in 231 HPNs, physical constraints have to be considered during spatial 232 routing. 234 Since physical impairments (see for instance [IPO-IMP]) may be 235 relevant at the wavelength granularity, the latter requirement is 236 confronted to the same scalability problem if this information is to 237 be flooded by a link state routing protocol. A solution would be to 238 appropriately aggregate physical impairment information at the TE 239 Link level. This would enable providing a summarized information on 240 signal degradation enabling TE Link selection during the LSP path 241 computation. 243 However, if the considered physical impairments are nearly static or 244 have long variation period they may not be flooded and just made 245 available for path selection by using another mechanism such as 246 using the management plane. Otherwise means to aggregate physical 247 impairments information and to disseminate this information will be 248 needed. 250 6.1.2. Shared Resources Availability 252 In photonic networks, taking into account physical impairments 253 during spatial routing without any information about regeneration is 254 of little relevance. It is considered that the regeneration 255 capability information will be flooded by a link state routing 256 protocol such as OSPF or ISIS. 258 In HPNs, regeneration resources are distributed between optical 259 nodes and thus limited in terms of number of sharable entities. The 260 information relative to regeneration resources availability is thus 261 of a statistical nature if given at the TE link level. Thus one 262 expects to be capable to apply a stochastic approach for the 263 regeneration resource availability (defining implicitly their 264 status). 266 6.1.3. Waveband Switching 268 Vigoureux et al. December 2002 5 269 GMPLS protocol suite, as currently defined, supports waveband 270 switching through inverse multiplexing or switching of individual 271 (contiguous) wavelength components. It may be thus appropriate to 272 integrate wavebands in the switching hierarchy in order to reflect, 273 at the control plane level, waveband physical components 274 (multiplexer/demultiplexer) availability at the data plane. Detailed 275 extensions are described in [GMPLS-WBEXT]. 277 Depending on the (passive/active) components used in an optical 278 network, wavelength spacing in the optical multiplex can vary. Some 279 components like multiplexer/demultiplexer impose or depend on that 280 spacing. It may be thus appropriate to detail the component 281 capability with respect to spacing, or to indicate the number of 282 supported wavelengths per waveband. Moreover, one may also expect in 283 case of (standardized) waveband nominal frequency values some 284 simplification during the corresponding wavelength assignment. 286 7. Signaling Considerations 288 The previous section highlighted the considerations with respect to 289 the routing protocols for enabling constraint based spatial routing 290 in hybrid photonic environments. 292 The current section focuses on the impact of HPNs on signaling 293 architecture by detailing spectral routing schemes mentioned above. 295 7.1. Schemes Comparison 297 In case of the second scheme (see Section 5.2.), the Label Set 298 reduction works according to an AND scheme. Each hop restricts the 299 label set sent to the next hop from the one received from the 300 previous hop by performing an AND operation between the wavelengths 301 referred by the Labels it includes the one available on the ongoing 302 interface. 304 This method generates a strong issue with regards to the probability 305 of having the Label Set reduced to an empty set of labels before 306 reaching the egress node (if each hop only proposes Labels referring 307 to wavelengths that are neither converted nor regenerated). 309 Note that using crank-back procedure can help reducing blocking 310 probability. A node may initiate a crank-back procedure if all 311 wavelengths referred in the Label Set coming from the upstream node 312 are not usable on the outgoing links to the downstream node. 313 - If conversion capabilities are available at this node and 314 accessible by the wavelengths referred in the Label Set coming from 315 the upstream node, the node may propose a new Label Set including 316 Labels accessible through conversion. 317 - If conversion functions are either not available in the node 318 or/nor accessible by the wavelengths referred in the Label Set 319 coming from the upstream node, the node may send a message 320 (including the Acceptable Label Set) to the upstream nodes in order 321 for the latter to propose new Labels (via conversion). 323 Vigoureux et al. December 2002 6 324 This message should contain an Acceptable Label Set (used as 325 feedback) for upstream nodes to intelligently propose new Labels. 327 Crank-back may reduce blocking probability but generates an issue 328 concerning signaling messages that may go back to the source and 329 forth many times before spectral path is found. Consequently, an 330 additional improvement should target intermediate Label Set 331 initialization point as (intermediate) destination of such messages 332 in order to avoid that the source (located behind the initialization 333 point) takes a contradictory decision based on the Acceptable Label 334 Set information. Moreover, it can be demonstrated that Label Set 335 utilization according to the AND scheme with crank-back feature is 336 sub-optimal with regards to the minimization of the number of 337 conversion/ regeneration points along the path. Nevertheless, in the 338 same context, only a global knowledge of spectral resources 339 availability along the spatial path enables optimal spectral path 340 computation. 342 It may be thus proposed to feed this information through signaling 343 using Label Set combined with an ALL scheme (i.e. also referred to 344 as �exhaustive scheme�) and do spectral path computation at the 345 egress node. This refers to third scheme. Note that the exhaustive 346 property may be relaxed according to a local policy in order to 347 reduce the amount of information exchange from the source to the 348 destination (i.e. over the entire LSP). 350 At each hop, the local Label Set object/TLV is appended to the Label 351 Set (more precisely to the list of Label Let objects). Additional 352 processing might be done at intermediate nodes depending on local 353 constraints and policy. The egress node receives the spectral 354 information collected along at least one spatial path. It can then 355 compute, using this spectral information, the optimal combination or 356 transparent sub-paths. 358 The third scheme has an added value compared to the second one. It 359 enables ensuring (a better) wavelength continuity while jointly 360 addressing regeneration needs along the path, though it requires 361 having the knowledge (at egress) of the ability a node to access 362 regeneration for a given wavelength. 364 The issue here is to make a clear differentiation between a Path 365 message with resource reservation and a so-called probing message, 366 defined as a message only probing for the resource availability. For 367 that purpose an additional status of the request can be defined in 368 the signaling protocol (for instance a specific Administrative 369 status flag, other solutions may also be considered). 371 So the following method can be considered: 372 - Path/Label Request message(s), along several but at least one 373 spatial explicit routes computed at ingress. 375 Vigoureux et al. December 2002 7 376 - Computation at the egress of the best combination of 377 transparent sub-paths. (Wavelength Labels containing the 378 necessary information for this purposes) 379 - Resv/Label Mapping message through the selected path 380 - PathErr/Notification messages to the non-selected path (if one 381 considers that releasing the reserved resources must be 382 performed) 384 Note: Wavelength Selection and Reservation 386 Downstream Wavelength Selection and Reservation can only be 387 considered with Selective AND scheme. The ALL Scheme with forward 388 (downstream) reservation is precluded since it would generate an 389 overwhelming blocking probability, so this method can only be used 390 with a backward (upstream) reservation. Nevertheless, Soft Selection 391 (control plane only) can be considered either with a Selective AND 392 and Exhaustive ALL scheme. 394 7.2. Wavelength Label Space and Values 396 As specified in [GMPLS-SIG], the Wavelength label space may include 397 either absolute values (channel identifiers (Channel ID) also 398 referred to as wavelength identifiers) or relative values (channel 399 spacing also referred to as inter-wavelength spacing). The latter is 400 strictly confined to a per-port label space while the former could 401 be defined as a local or a global (per node) label space. 403 However, both wavelength selection schemes listed above require the 404 knowledge of the mapping between collected Labels and the wavelength 405 spectral-related information they locally refer. Therefore, in this 406 context, it is proposed to define an association between the Label 407 value and the wavelength spectral information. 409 In the second scheme, upstream nodes receiving an Acceptable Label 410 Set message, due to the crank-back procedure, must be able to 411 understand which wavelengths these Labels refer to. In third scheme, 412 the egress node must also know which wavelengths the Labels refer to 413 in order to achieve the expected wavelength continuity. 415 In order to decide where regeneration/conversion should be ideally 416 performed because of signal degradation/blocking probabilities, 417 knowledge of the capability of a wavelength to be regenerated is 418 also important. 420 The definition of the association between the Label value and the 421 wavelength spectral information is achieved by specifying semantic- 422 full and dedicated fields in the 32 bits Label. This specification 423 simply corresponds to a Label value assignment rule and still 424 ensures backward compatibility for nodes not able to understand the 425 hereafter defined semantic. 427 Vigoureux et al. December 2002 8 428 This Label may for instance include the following information 429 reflecting the spectral capabilities and attributes of the selected 430 Label: 432 R : set by the node proposing the Label. Informs whether the 433 corresponding wavelength can be regenerated or not. 435 C : set by the node proposing the Label. Informs whether the 436 corresponding wavelength can be converted or not. 438 A : set by the next downstream node receiving the proposed Labels. 439 Informs whether wavelengths can have access to regeneration 440 functionality in this node. This indication is primarily used by 441 nodes presenting blocking architectures with respect to their 442 amplification capabilities. For instance, amplification can be 443 performed in the C-Band, L-Band, S-Band, etc. 445 Wavelength Index : Identifies the wavelength in the Amplification 446 Band by considering minimum spacing. 448 Wavelength Identifier : Used to differentiate Labels (proposed for 449 example in a Label Set) that would have same values of the fields 450 listed above. 452 Other definitions not detailed here may also be used for the same 453 purpose. It should be also noticed that such label space definition 454 does not in the absolute sense bring any backward compatibility 455 issue with respect to [GMPLS-SIG]. In particular one assumes here 456 that local node may still convert these values into an internal one 457 no specific procedures should be defined to achieve backward 458 compatibility. 460 7.3. Comparison Example 462 The following example illustrates the different results that may be 463 obtained, for a spectral path computation, when using the second and 464 third schemes. 466 Consider a spatial path composed of nine wavelength switching nodes 467 with shared converters (both in the optical domain). In this 468 example, only available resources are mentioned and are described as 469 follows: 470 - Li-T means that interface i is transparent (neither going through 471 a converter converted nor a regenerator) 472 - Lj-C means that interface j is converted 474 Note that in case of nodes having conversion on all interfaces, the 475 second scheme is still compatible. 477 Available wavelengths on the outgoing links and thus not requiring 478 conversion (even though going through a converter) are considered as 479 transparent and corresponding Labels can thus be proposed. 481 Vigoureux et al. December 2002 9 482 Node 1 has available L2-C and L4-C 483 Node 2 has available L4-T and L6-C 484 Node 3 has available L4-T and L6-T 485 Node 4 has available L4-T, L6-T and L7-C 486 Node 5 has available L4-T, L6-T and L7-T 487 Node 6 has available L6-T and L7-T 488 Node 7 has available L6-T and L7-T 489 Node 8 has available L6-T and L8-C 490 Node 9 has available L6-T and L8-C 492 For second scheme (with crank-back) wavelength selection will go as 493 follows: Node 1 proposes the Labels L2 and L4 that Node 2 restricts 494 to L4 (only transparent wavelength). Reaching Node 5, the Label L4 495 is sent towards Node 6, which has free output interfaces but no 496 available conversion function. 498 Message is thus sent back upstream (maybe with an Acceptable Label 499 Set, L6 and L7 in this case) until a node can perform conversion. 500 Therefore, the feedback (i.e. the Acceptable Label Set) is used by 501 Nodes having enough free resources to perform wavelength conversion. 502 Here, the message arrives back to Node 4 which can perform 503 conversion from L4 to L7. Node 4 sends Label Set L7 which is 504 propagated down to Node 8. L7 is not available at Node 8 output but 505 can be converted to L8 (Node 8 does crank-back on itself). 507 The resulting spectral path can be represented as: 509 L4 L4 L4 L7 L7 L7 L7 L8 510 N1------N2------N3------N4------N5------N6------N7------N8------N9 512 Using the third scheme, each node, proposing all of its free output 513 Labels, the result would have been: 515 L4 L6 L6 L6 L6 L6 L6 L6 516 N1------N2------N3------N4------N5------N6------N7------N8------N9 518 Therefore, the second scheme will result in using two conversion 519 points (at Node 4 and Node 8) along the path, while third scheme 520 will result in using only one (at Node 2). 522 8. Other issues 524 This section details other GMPLS architectural issues in the scope 525 of the hybrid photonic networks: 527 8.1 Bi-directional LSPs 529 When using the second selection scheme, two mechanisms must be 530 considered depending on the directionality of the LSP: 532 1) Unidirectional LSP: (downstream) label set 533 2) Bi-directional LSP: (downstream) label set and upstream label 535 Vigoureux et al. December 2002 10 536 The first improvement that may be provided is to extend the upstream 537 label to an upstream label set, thus one would have the following 538 symmetric approach when using an AND label selection scheme: 540 1) Unidirectional selection scheme: (downstream) label set 541 2) Bi-directional selection scheme: (downstream) label set and 542 upstream label set 544 The Resv/Label mapping message will then either include the 545 downstream label in addition to the upstream label, in case of bi- 546 directional LSP. Notice that here both labels are selected at the 547 egress. Detailed extensions concerning the upstream label set are 548 described in [OKI-UPSTREAM]. 550 The same applies in case of exhaustive label selection scheme. The 551 ALL scheme when used for bi-directional path setup must take into 552 account not only outgoing spectral routing information but also 553 incoming spectral routing information and perform the selection at 554 the destination based on a correlation basis for both upstream and 555 downstream flows. 557 8.2 Prioritized Label Sets 559 Signaling extensions may be also considered to ease forward-link 560 label unavailability when the downstream label selection is 561 restricted by the upstream node using the Label Set (see [GMPLS- 562 SIG]). [OZU-FLAGS] allows relaxing backward-link label collision by 563 introducing a Flagged Label Set object/TLV in order to prioritize 564 the reservation of the labels included in the Label Set and enabling 565 to decrease the forward- and backward-link blocking probability. 567 In order to prioritize the label reservation, each set of labels is 568 inserted by each hop along the path into the Flagged Label Set with 569 a certain priority. Each node keeps track of each label by using a 570 local timestamp indicating when the label has been reserved but not 571 selected yet with respect to any other previous label set. A pool 572 points to these labels and provides a gray area for the labels, 573 which are subject to collision. It may be seen as an intermediate 574 state between the labels belonging to the used pool of labels 575 (reserved and selected) and the ones belonging to the available pool 576 of labels (neither reserved nor selected). 578 Other prioritization methods may be considered in future releases of 579 this document. 581 8.3 Branching and K-(C)SPF 583 TBD. 585 9. Security Considerations 587 This memo does not introduce new security consideration from the 588 ones already detailed in the GMPLS protocol suite. 590 Vigoureux et al. December 2002 11 591 10. References 593 [GMPLS-ARCH] E.Mannie (Editor) et al., 594 "Generalized Multi-Protocol Label Switching (GMPLS) 595 Architecture", Work in progress, 596 draft-ietf-ccamp-gmpls-architecture-02.txt 598 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al., 599 "IS-IS Extensions in Support of Generalized MPLS", Work 600 in progress, 601 draft-ietf-isis-gmpls-extensions-12.txt 603 [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al., 604 "OSPF Extensions in Support of Generalized MPLS", Work 605 in progress, 606 draft-ietf-ccamp-ospf-gmpls-extensions-07.txt 608 [GMPLS-SIG] Ashwood-Smith, P. et al., 609 "Generalized MPLS-Signaling Functional Description", 610 Work in progress, 611 draft-ietf-mpls-generalized-signaling-08.txt 613 [GMPLS-RTG] Kompella, K., Rekhter, Y., Banerjee, A. et al., 614 "Routing Extensions in Support of Generalized MPLS", 615 Work in progress, 616 draft-ietf-ccamp-gmpls-routing-04.txt 618 [GMPLS-WBEXT] Douville R. et al., 619 "Extensions to Generalized MPLS for Waveband 620 Switching", Work in progress, 621 draft-douville-ccamp-gmpls-waveband-extensions-01.txt 623 [IPO-IMP] A. Chiu et al., 624 "Impairments And Other Constraints On Optical Layer 625 Routing", Work in progress, 626 draft-ietf-ipo-impairments-02.txt. 628 [ISIS-TE] Smit, H., Li, T., 629 "IS-IS Extensions for Traffic Engineering", Work in 630 progress, 631 draft-ietf-isis-traffic-04.txt 633 [OKI-IPO] E. Oki et al., 634 �Requirements of optical link-state information for 635 traffic engineering�, Work in progress, 636 draft-oki-ipo-optlink-req-00.txt 638 [OKI-UPSTREAM] E. Oki et al., 639 �Upstream Label Set Support in RSVP-TE extensions�, 640 Work in progress, 641 draft-oki-ccamp-upstream-labelset-00.txt 643 Vigoureux et al. December 2002 12 645 [OZU-FLAGS] T.Ozugur et al., 646 �Label Set Priority and Flagging Operations�, Work in 647 progress, 648 draft-ozugur-ccamp-gmpls-label-flag-00.txt 650 [ONM-1] �A comparative study of distributed protocols for 651 wavelength reservation in WDM Optical networks, Optical 652 Network Magazine, January 2002. 654 [OSPF-TE] Katz, D., Yeung, D., 655 "Traffic Engineering Extensions to OSPF", Work in 656 progress, 657 draft-katz-yeung-ospf-traffic-06.txt 659 11. Acknowledgments 661 We would like, here, to thank Richard Douville, Olivier Audouin, 662 Emmanuel Desmet as well as Amaury Jourdan and Bernard Sales. 664 The authors would like also to thank Kohei Shiomoto and Nobuaki 665 Matsuura of NTT for their contribution to this memo. 667 12. Author's Addresses 669 Eiji Oki (NTT) 670 3-9-11 Midori 671 Musashino, Tokyo 180-8585, Japan 672 Email: oki.eiji@lab.ntt.co.jp 674 Wataru Imajuku (NTT) 675 1-1 Hikari-no-oka 676 Yokosuka, Kanagawa 239-0847, Japan 677 Email: imajuku@exa.onlab.ntt.co.jp 679 Naoaki Yamanaka (NTT) 680 3-9-11 Midori-cho 681 Musashino-shi, Tokyo 180-8585, Japan 682 Email: yamanaka.naoaki@lab.ntt.co.jp 684 Emmanuel Dotaro (Alcatel) 685 Route de Nozay, 91460 Marcoussis, France 686 Phone: +33 1 6963-4723 687 Email: emmanuel.dotaro@alcatel.fr 689 Dimitri Papadimitriou (Alcatel) 690 Francis Wellesplein 1, B-2018 Antwerpen, Belgium 691 Phone: +32 3 240-8491 692 Email: dimitri.papadimitriou@alcatel.be 694 Martin Vigoureux (Alcatel) 695 Route de Nozay, 91460 Marcoussis, France 696 Phone: +33 1 6963-1852 698 Vigoureux et al. December 2002 13 699 Email: martin.vigoureux@alcatel.fr 701 Vigoureux et al. December 2002 14 702 Full Copyright Statement 704 "Copyright (C) The Internet Society (date). All Rights Reserved. 705 This document and translations of it may be copied and furnished to 706 others, and derivative works that comment on or otherwise explain it 707 or assist in its implementation may be prepared, copied, published 708 and distributed, in whole or in part, without restriction of any 709 kind, provided that the above copyright notice and this paragraph 710 are included on all such copies and derivative works. However, this 711 document itself may not be modified in any way, such as by removing 712 the copyright notice or references to the Internet Society or other 713 Internet organizations, except as needed for the purpose of 714 developing Internet standards in which case the procedures for 715 copyrights defined in the Internet Standards process must be 716 followed, or as required to translate it into languages other than 717 English. 719 The limited permissions granted above are perpetual and will not be 720 revoked by the Internet Society or its successors or assigns. 722 This document and the information contained herein is provided on an 723 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 724 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 725 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 726 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 727 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 729 Vigoureux et al. December 2002 15