idnits 2.17.1 draft-ietf-ccamp-gmpls-architecture-03.txt: -(2835): 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 7 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 57 longer pages, the longest (page 2) being 59 lines 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. 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 (August 2002) is 7923 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) -- Looks like a reference, but probably isn't: '1' on line 14 -- Looks like a reference, but probably isn't: '2' on line 287 == Missing Reference: 'LMP' is mentioned on line 3028, but not defined == Missing Reference: 'ISIS-GMPLS' is mentioned on line 863, but not defined == Missing Reference: 'OSPF-GMPLS' is mentioned on line 863, but not defined == Missing Reference: 'BUNDLE' is mentioned on line 3046, but not defined == Missing Reference: 'ISIS-TE' is mentioned on line 2289, but not defined == Missing Reference: 'GMPLS-ROUTING' is mentioned on line 3049, but not defined == Missing Reference: 'RSVP-TE-GMPLS' is mentioned on line 3011, but not defined == Missing Reference: 'CR-LDP-GMPLS' is mentioned on line 3014, but not defined == Missing Reference: 'OIF-UNI' is mentioned on line 1147, but not defined == Missing Reference: 'LMP-WDM' is mentioned on line 3034, but not defined == Missing Reference: 'GMPLS' is mentioned on line 1422, but not defined == Missing Reference: 'GMPLS-SIG' is mentioned on line 3008, but not defined == Missing Reference: 'SONETSDH-GMPLS' is mentioned on line 3017, but not defined == Missing Reference: 'G709-GMPLS' is mentioned on line 3024, but not defined == Missing Reference: 'SONETSDH-EXT-GMPLS' is mentioned on line 3020, but not defined == Missing Reference: 'RSVP-TE' is mentioned on line 1907, but not defined == Missing Reference: 'CR-LDP' is mentioned on line 1908, but not defined == Missing Reference: 'RSVP' is mentioned on line 1996, but not defined == Missing Reference: 'HIERARCHY' is mentioned on line 3037, but not defined == Missing Reference: 'OSPF-TE-GMPLS' is mentioned on line 3052, but not defined == Missing Reference: 'ISIS-TE-GMPLS' is mentioned on line 3055, but not defined == Missing Reference: 'LDP-FT' is mentioned on line 2465, but not defined == Missing Reference: 'TEWG-RESTORE' is mentioned on line 2493, but not defined == Missing Reference: 'RSVP-TE-UNNUM' is mentioned on line 3040, but not defined == Missing Reference: 'CR-LDP-UNNUM' is mentioned on line 3043, but not defined == Unused Reference: 'RFC2119' is defined on line 3104, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 3107, but no explicit reference was found in the text == Unused Reference: 'RFC2370' is defined on line 3110, but no explicit reference was found in the text == Unused Reference: 'RFC3032' is defined on line 3136, but no explicit reference was found in the text == Unused Reference: 'MPLS-TEO' is defined on line 3152, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1393 (Obsoleted by RFC 6814) ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (Obsoleted by RFC 2580) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2575 (ref. 'SNMPv3VACM') (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 1739 (Obsoleted by RFC 2151) ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2925 (Obsoleted by RFC 4560) ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) -- No information found for draft-katz-yeung-ospf- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'OSPF-TE' -- Possible downref: Normative reference to a draft: ref. 'MPLS-TEO' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.841' == Outdated reference: A later version (-01) exists of draft-ietf-tewg-restore-hierarchy-00 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-restore-hierarchy (ref. 'TE-RESTORE') == Outdated reference: A later version (-08) exists of draft-ietf-mpls-recovery-frmwrk-06 ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-recovery-frmwrk (ref. 'MPLS-RECOVERY') -- Possible downref: Normative reference to a draft: ref. 'OLI-REQ' -- Possible downref: Non-RFC (?) normative reference: ref. 'MANCHESTER' Summary: 22 errors (**), 0 flaws (~~), 36 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Eric Mannie - Editor 3 Internet Draft 4 Expiration date: Feb. 2003 August 2002 6 Generalized Multi-Protocol Label Switching (GMPLS) Architecture 8 draft-ietf-ccamp-gmpls-architecture-03.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet- Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 Future data and transmission networks will consist of elements such 34 as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), 35 photonic cross-connects (PXCs), optical cross-connects (OXCs), etc 36 that will use Generalized MPLS (GMPLS) to dynamically provision 37 resources and to provide network survivability using protection and 38 restoration techniques. 40 This document describes the architecture of GMPLS. GMPLS extends 41 MPLS to encompass time-division (e.g. SDH/SONET, PDH, G.709), 42 wavelength (lambdas), and spatial switching (e.g. incoming port or 43 fiber to outgoing port or fiber). The main focus of GMPLS is on the 44 control plane of these various layers since each of them can use 45 physically diverse data or forwarding planes. The intention is to 46 cover both the signaling and the routing part of that control plane. 48 E. Mannie et. al. 1 49 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 51 Table of Contents 53 Status of this Memo................................................1 54 Abstract...........................................................1 55 Table of Contents..................................................2 56 1. Contributors....................................................4 57 2. Conventions used in this document...............................7 58 3. Introduction....................................................7 59 3.1. Acronyms & abbreviations......................................7 60 3.2. Multiple Types of Switching and Forwarding Hierarchies........8 61 3.3. Extension of the MPLS Control Plane..........................10 62 3.4. GMPLS Key Extensions to MPLS-TE..............................12 63 4. Routing and addressing model...................................13 64 4.1. Addressing of PSC and non-PSC layers.........................14 65 4.2. GMPLS scalability enhancements...............................15 66 4.3. TE Extensions to IP routing protocols........................15 67 5. Unnumbered links...............................................16 68 5.1. Unnumbered Forwarding Adjacencies............................17 69 6. Link bundling..................................................18 70 6.1. Restrictions on bundling.....................................18 71 6.2. Routing considerations for bundling..........................18 72 6.3. Signaling considerations.....................................19 73 6.3.1. Mechanism 1: Implicit Indication...........................20 74 6.3.2. Mechanism 2: Explicit Indication by Numbered Interface ID..20 75 6.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID20 76 6.4. Unnumbered Bundled Link......................................20 77 6.5. Forming bundled links........................................21 78 7. Relationship with the UNI......................................21 79 7.1. Relationship with the OIF UNI................................22 80 7.2. Reachability across the UNI..................................22 81 8. Link Management................................................23 82 8.1. Control channel and control channel management...............23 83 8.2. Link property correlation....................................25 84 8.3. Link connectivity verification...............................25 85 8.4. Fault management.............................................25 86 8.5 LMP for DWDM Optical Line Systems (OLSs)......................26 87 9. Generalized Signaling..........................................27 88 9.1. Overview: How to Request an LSP..............................29 89 9.2. Generalized Label Request....................................30 90 9.3. SONET/SDH Traffic Parameters.................................31 91 9.4. G.709 Traffic Parameters.....................................32 92 9.5. Bandwidth Encoding...........................................32 93 9.6. Generalized Label............................................33 94 9.7. Waveband Switching...........................................33 95 9.8. Label Suggestion by the Upstream.............................34 96 9.9. Label Restriction by the Upstream............................34 97 9.10. Bi-directional LSP..........................................35 98 9.11. Bi-directional LSP Contention Resolution....................36 99 9.12. Rapid Notification of Failure...............................36 100 9.13. Link Protection.............................................37 101 9.14. Explicit Routing and Explicit Label Control.................37 102 9.15. Route recording.............................................38 103 9.16. LSP modification and LSP re-routing.........................39 104 9.17. LSP administrative status handling..........................39 106 E. Mannie et. al. Internet-Draft February 2003 2 107 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 109 9.18. Control channel separation..................................40 110 10. Forwarding Adjacencies (FA)...................................41 111 10.1. Routing and Forwarding Adjacencies..........................41 112 10.2. Signaling aspects...........................................42 113 10.3. Cascading of Forwarding Adjacencies.........................42 114 11. Routing and Signaling Adjacencies.............................43 115 12. Control Plane Fault Handling..................................44 116 13. LSP Protection and Restoration................................45 117 13.1. Protection escalation across domains and layers.............46 118 13.2. Mapping of Services to P&R Resources........................46 119 13.3. Classification of P&R mechanism characteristics.............47 120 13.4. Different Stages in P&R.....................................47 121 13.5. Recovery Strategies.........................................48 122 13.6. Recovery mechanisms: Protection schemes.....................48 123 13.7. Recovery mechanisms: Restoration schemes....................49 124 13.8. Schema selection criteria...................................50 125 14. Network Management............................................51 126 14.1. Network Management Systems (NMS)............................51 127 14.2. Management Information Base (MIB)...........................52 128 14.3. Tools.......................................................52 129 14.4. Fault Correlation Between Multiple Layers...................52 130 15. Security considerations.......................................53 131 16. Acknowledgements..............................................54 132 17. References....................................................55 133 18. Author's Address..............................................57 134 Full Copyright Statement..........................................58 136 E. Mannie et. al. Internet-Draft February 2003 3 137 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 139 1. Contributors 141 Peter Ashwood-Smith Eric Mannie 142 Nortel Networks Corp. Ebone (GTS) 143 P.O. Box 3511 Station C, Terhulpsesteenweg 6A 144 Ottawa, ON K1Y 4H7 1560 Hoeilaart 145 Canada Belgium 146 Phone: +1 613 763-4534 Phone: +32 2 658-5652 147 Email: Email: eric.mannie@gts.com 148 petera@nortelnetworks.com 150 Daniel O. Awduche Thomas D. Nadeau 151 Movaz Networks Cisco Systems, Inc. 152 7296 Jones Branch Drive 250 Apollo Drive 153 Suite 615 Chelmsford, MA 01824 154 McLean, VA 22102 USA 155 USA Phone: +1 978 244-3051 156 Phone: +1 703 847-7350 Email: tnadeau@cisco.com 157 Email: awduche@movaz.com 159 Ayan Banerjee Lyndon Ong 160 Calient Networks Ciena Systems 161 5853 Rue Ferrari 10480 Ridgeview Ct 162 San Jose, CA 95138 Cupertino, CA 95014 163 USA USA 164 Phone: +1 408 972-3645 Email: lyong@ciena.com 165 Email: abanerjee@calient.net 167 Debashis Basak Dimitri Papadimitriou 168 Accelight Networks Alcatel 169 70 Abele Road, Bldg.1200 Francis Wellesplein, 1 170 Bridgeville, PA 15017 B-2018 Antwerpen 171 USA Belgium 172 Phone: +1 412 220-2102 (ext115) Phone: +32 3 240-8491 173 email: dbasak@accelight.com Email: 174 dimitri.papadimitriou@alcatel.be 176 Lou Berger Dimitrios Pendarakis 177 Movaz Networks, Inc. Tellium, Inc. 178 7926 Jones Branch Drive 2 Crescent Place 179 Suite 615 P.O. Box 901 180 MCLean VA, 22102 Oceanport, NJ 07757-0901 181 USA USA 182 Phone: +1 703 847-1801 Email: DPendarakis@tellium.com 183 Email: lberger@movaz.com 185 E. Mannie et. al. Internet-Draft February 2003 4 186 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 188 Greg Bernstein Bala Rajagopalan 189 Ciena Corporation Tellium, Inc. 190 10480 Ridgeview Court 2 Crescent Place 191 Cupertino, CA 94014 P.O. Box 901 192 USA Oceanport, NJ 07757-0901 193 Phone: +1 408 366-4713 USA 194 Email: greg@ciena.com Phone: +1 732 923-4237 195 Email: braja@tellium.com 197 Sudheer Dharanikota Yakov Rekhter 198 Nayna Networks Inc. Juniper 199 481 Sycamore Drive Email: yakov@juniper.net 200 Milpitas, CA 95035 201 USA 202 Email: sudheer@nayna.com 204 John Drake Debanjan Saha 205 Calient Networks Tellium Optical Systems 206 5853 Rue Ferrari 2 Crescent Place 207 San Jose, CA 95138 Oceanport, NJ 07757-0901 208 USA USA 209 Phone: +1 408 972-3720 Phone: +1 732 923-4264 210 Email: jdrake@calient.net Email: dsaha@tellium.com 212 Yanhe Fan Hal Sandick 213 Axiowave Networks, Inc. Nortel Networks 214 200 Nickerson Road Email: 215 Marlborough, MA 01752 hsandick@nortelnetworks.com 216 USA 217 Phone: +1 774 348-4627 218 Email: yfan@axiowave.com 220 Don Fedyk Vishal Sharma 221 Nortel Networks Corp. Metanoia, Inc. 222 600 Technology Park Drive 305 Elan Village Lane, Unit 223 Billerica, MA 01821 121 224 USA San Jose, CA 95134-2545 225 Phone: +1 978 288-4506 USA 226 Email: Phone: +1 408 895-5030 227 dwfedyk@nortelnetworks.com Email: vsharma87@yahoo.com 229 Gert Grammel George Swallow 230 Alcatel Cisco Systems, Inc. 231 Via Trento, 30 250 Apollo Drive 232 20059 Vimercate (Mi) Chelmsford, MA 01824 233 Italy USA 234 Email: gert.grammel@alcatel.it Phone: +1 978 244-8143 235 Email: swallow@cisco.com 237 E. Mannie et. al. Internet-Draft February 2003 5 238 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 240 Dan Guo Z. Bo Tang 241 Turin Networks, Inc. Tellium, Inc. 242 1415 N. McDowell Blvd, 2 Crescent Place 243 Petaluma, CA 95454 P.O. Box 901 244 USA Oceanport, NJ 07757-0901 245 Email: dguo@turinnetworks.com USA 246 Phone: +1 732 923-4231 247 Email: btang@tellium.com 249 Kireeti Kompella Jennifer Yates 250 Juniper Networks, Inc. AT&T 251 1194 N. Mathilda Ave. 180 Park Avenue 252 Sunnyvale, CA 94089 Florham Park, NJ 07932 253 USA USA 254 Email: kireeti@juniper.net Email: jyates@research.att.com 256 Alan Kullberg George R. Young 257 NetPlane Systems, Inc. Edgeflow 258 888 Washington St. 329 March Road 259 Dedham, MA 02026 Ottawa, Ontario, K2K 2E1 260 USA Canada 261 Phone: +1 781 251-5319 Email: 262 Email: akullber@netplane.com george.young@edgeflow.com 264 Jonathan P. Lang John Yu 265 Calient Networks Zaffire Inc. 266 25 Castilian 2630 Orchard Parkway 267 Goleta, CA 93117 San Jose, CA 95134 268 Email: jplang@calient.net USA 269 Email: jzyu@zaffire.com 271 Fong Liaw Alex Zinin 272 Zaffire Inc. Alcatel 273 2630 Orchard Parkway 1420 North McDowell Ave 274 San Jose, CA 95134 M/S 1400-HRPB6 275 USA Petaluma, CA 94954 276 Email: fliaw@zaffire.com USA 277 Email: alex.zinin@alcatel.com 279 E. Mannie et. al. Internet-Draft February 2003 6 280 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 282 2. Conventions used in this document 284 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 285 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 286 this document are to be interpreted as described in RFC-2119 [2]. 288 3. Introduction 290 The architecture presented in this document covers the main building 291 blocks needed to build a consistent control plane for multiple 292 switching layers. It does not restrict the way that these layers 293 work together. Different models can be applied: e.g. overlay, 294 augmented or integrated. Moreover, each pair of contiguous layer may 295 work jointly in a different way, resulting in a number of possible 296 combinations, at the discretion of manufacturers and operators. 298 This architecture clearly separates the control plane and the 299 forwarding plane. In addition, it also clearly separates the control 300 plane in two parts, the signaling plane containing the signaling 301 protocols and the routing plane containing the routing protocols. 303 This document is a generalization of the MPLS architecture 304 [RFC3031], and in some cases may differ slightly from that 305 architecture since non packet-based forwarding planes are now 306 considered. It is not the intention of this document to describe 307 concepts already described in the current MPLS architecture. The 308 goal is to describe specific concepts of Generalized MPLS (GMPLS). 310 However, some of the concepts explained hereafter are not part of 311 the current MPLS architecture and are applicable to both MPLS and 312 GMPLS (i.e. link bundling, unnumbered links, and LSP hierarchy). 313 Since these concepts were introduced together with GMPLS and since 314 they are of paramount importance for an operational GMPLS network, 315 they will be discussed here. 317 The organization of the remainder of this draft is as follows. We 318 begin with an introduction of GMPLS. We then present the specific 319 GMPLS building blocks and explain how they can be combined together 320 to build an operational GMPLS networks. Specific details of the 321 separate building blocks can be found in the corresponding 322 documents. 324 3.1. Acronyms & abbreviations 326 ABR Area Border Router 327 AS Autonomous System 328 ASBR Autonomous System Boundary Router 329 BGP Border Gateway Protocol 330 CR-LDP Constraint-based Routing LDP 331 CSPF Constraint-based Shortest Path First 332 DWDM Dense Wavelength Division Multiplexing 333 FA Forwarding Adjacency 334 GMPLS Generalized Multi-Protocol Label Switching 335 IGP Interior Gateway Protocol 337 E. Mannie et. al. Internet-Draft February 2003 7 338 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 340 LDP Label Distribution Protocol 341 LMP Link Management Protocol 342 LSA Link State Advertisement 343 LSR Label Switching Router 344 LSP Label Switched Path 345 MIB Management Information Base 346 MPLS Multi-Protocol Label Switching 347 NMS Network Management System 348 OXC Optical Cross-Connect 349 PXC Photonic Cross-Connect 350 RSVP ReSource reserVation Protocol 351 SDH Synchronous Digital Hierarchy 352 STM(-N) Synchronous Transport Module (-N) 353 STS(-N) Synchronous Transport Signal-Level N (SONET) 354 TE Traffic Engineering 356 3.2. Multiple Types of Switching and Forwarding Hierarchies 358 Generalized MPLS (GMPLS) differs from traditional MPLS in that it 359 supports multiple types of switching, i.e. the addition of support 360 for TDM, lambda, and fiber (port) switching. The support for the 361 additional types of switching has driven GMPLS to extend certain 362 base functions of traditional MPLS and, in some cases, to add 363 functionality. These changes and additions impact basic LSP 364 properties, how labels are requested and communicated, the 365 unidirectional nature of LSPs, how errors are propagated, and 366 information provided for synchronizing the ingress and egress LSRs. 368 The MPLS architecture [RFC3031] was defined to support the 369 forwarding of data based on a label. In this architecture, Label 370 Switching Routers (LSRs) were assumed to have a forwarding plane 371 that is capable of (a) recognizing either packet or cell boundaries, 372 and (b) being able to process either packet headers (for LSRs 373 capable of recognizing packet boundaries) or cell headers (for LSRs 374 capable of recognizing cell boundaries). 376 The original MPLS architecture is here being extended to include 377 LSRs whose forwarding plane recognizes neither packet, nor cell 378 boundaries, and therefore, can't forward data based on the 379 information carried in either packet or cell headers. Specifically, 380 such LSRs include devices where the forwarding decision is based on 381 time slots, wavelengths, or physical ports. So, the new set of LSRs, 382 or more precisely interfaces on these LSRs, can be subdivided into 383 the following classes: 385 1. Packet Switch Capable (PSC) interfaces: 387 Interfaces that recognize packet boundaries and can forward data 388 based on the content of the packet header. Examples include 389 interfaces on routers that forward data based on the content of the 390 IP header and interfaces on routers that forward data based on the 391 content of the MPLS "shim" header. 393 2. Layer-2 Switch Capable (L2SC) interfaces: 395 E. Mannie et. al. Internet-Draft February 2003 8 396 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 398 Interfaces that recognize frame/cell boundaries and can forward data 399 based on the content of the frame/cell header. Examples include 400 interfaces on Ethernet bridges that forward data based on the 401 content of the MAC header and interfaces on ATM-LSRs that forward 402 data based on the ATM VPI/VCI. 404 3. Time-Division Multiplex Capable (TDM) interfaces: 406 Interfaces that forward data based on the data's time slot in a 407 repeating cycle. An example of such an interface is that of a 408 SDH/SONET Cross-Connect (XC), Terminal Multiplexer (TM), or Add-Drop 409 Multiplexer (ADM). Other examples include interfaces providing G.709 410 TDM capabilities (the "digital wrapper") and PDH interfaces. 412 4. Lambda Switch Capable (LSC) interfaces: 414 Interfaces that forward data based on the wavelength on which the 415 data is received. An example of such an interface is that of a 416 Photonic Cross-Connect (PXC) or Optical Cross-Connect (OXC) that can 417 operate at the level of an individual wavelength. Additional 418 examples include PXC interfaces that can operate at the level of a 419 group of wavelengths, i.e. a waveband and G.709 interfaces providing 420 optical capabilities. 422 5. Fiber-Switch Capable (FSC) interfaces: 424 Interfaces that forward data based on a position of the data in the 425 real world physical spaces. An example of such an interface is that 426 of a PXC or OXC that can operate at the level of a single or 427 multiple fibers. 429 A circuit can be established only between, or through, interfaces of 430 the same type. Depending on the particular technology being used for 431 each interface, different circuit names can be used, e.g. SDH 432 circuit, optical trail, light-path, etc. In the context of GMPLS, 433 all these circuits are referenced by a common name: Label Switched 434 Path (LSP). 436 The concept of nested LSP (LSP within LSP), already available in the 437 traditional MPLS, facilitates building a forwarding hierarchy, i.e. 438 a hierarchy of LSPs. This hierarchy of LSPs can occur on the same 439 interface, or between different interfaces. 441 For example, a hierarchy can be built if an interface is capable of 442 multiplexing several LSPs from the same technology (layer), e.g. a 443 lower order SDH/SONET LSP (VC-12) nested in a higher order SDH/SONET 444 LSP (VC-4). Several levels of signal (LSP) nesting are defined in 445 the SDH/SONET multiplexing hierarchy. 447 The nesting can also occur between interfaces. At the top of the 448 hierarchy are FSC interfaces, followed by LSC interfaces, followed 449 by TDM interfaces, followed by L2SC, and followed by PSC interfaces. 450 This way, an LSP that starts and ends on a PSC interface can be 452 E. Mannie et. al. Internet-Draft February 2003 9 453 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 455 nested (together with other LSPs) into an LSP that starts and ends 456 on a L2SC interface. This LSP, in turn, can be nested (together with 457 other LSPs) into an LSP that starts and ends on an TDM interface, 458 which in turn can be nested (together with other LSPs) into an LSP 459 that starts and ends on a LSC interface, which in turn can be nested 460 (together with other LSPs) into an LSP that starts and ends on a FSC 461 interface. 463 3.3. Extension of the MPLS Control Plane 465 The establishment of LSPs that span only Packet Switch Capable (PSC) 466 or Layer-2 Switch Capable (L2SC) interfaces is defined for the 467 original MPLS and/or MPLS-TE control planes. GMPLS extends these 468 control planes to support each of the five classes of interfaces 469 (i.e. layers) defined in the previous section. 471 Note that the GMPLS control plane supports an overlay model, an 472 augmented model, and a peer (integrated) model. In the near term, 473 GMPLS is very suitable for controlling each layer independently. 474 This elegant approach will facilitate the future deployment of other 475 models. 477 The GMPLS control plane is made of several building blocks are 478 described in more detail in the following sections. These building 479 blocks are based on well-known signaling and routing protocols that 480 have been extended and/or modified to support GMPLS. They use IPv4 481 and/or IPv6 addresses. Only one new specialized protocol is required 482 to support the operations of GMPLS, a signaling protocol for link 483 management [LMP]. 485 GMPLS is indeed based on the Traffic Engineering (TE) extensions to 486 MPLS, a.k.a. MPLS-TE. This because most of the technologies that can 487 be used below the PSC level require some traffic engineering. The 488 placement of LSPs at these levels needs in general to take several 489 constraints into consideration (such as framing, bandwidth, 490 protection capability, etc) and to bypass the legacy Shortest-Path 491 First (SPF) algorithm. Note, however, that this is not mandatory and 492 that in some cases SPF routing can be applied. 494 In order to facilitate constrained-based SPF routing of LSPs, the 495 nodes performing LSP establishment need more information about the 496 links in the network than standard intra-domain routing protocols 497 provide. These TE attributes are distributed using the transport 498 mechanisms already available in IGPs (e.g. flooding) and taken into 499 consideration by the LSP routing algorithm. Optimization of the LSP 500 routes may also require some external simulations using heuristics 501 that serve as input for the actual path calculation and LSP 502 establishment process. 504 By definition, a TE link is a representation in the ISIS/OSPF Link 505 State advertisements and in the link state database of certain 506 physical resources, and their properties, between two GMPLS nodes. 507 TE Links are used by the GMPLS control plane (routing and signaling) 508 for establishing LSPs. 510 E. Mannie et. al. Internet-Draft February 2003 10 511 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 513 Extensions to traditional routing protocols and algorithms are 514 needed to uniformly encode and carry TE link information, and 515 explicit routes (e.g. source routes) are required in the signaling. 516 In addition, the signaling must now be capable of transporting the 517 required circuit (LSP) parameters such as the bandwidth, the type of 518 signal, the desired protection and/or restoration, the position in a 519 particular multiplex, etc. Most of these extensions have already 520 been defined for PSC and L2SC traffic engineering with MPLS. GMPLS 521 primarily defines additional extensions for TDM, LSC, and FSC 522 traffic engineering. A very few elements are technology specific. 524 Thus, GMPLS extends the two signaling protocols defined for MPLS-TE 525 signaling, i.e. RSVP-TE and CR-LDP. However, GMPLS does not specify 526 which one of these two signaling protocols must be used. It is the 527 role of manufacturers and operators to evaluate the two possible 528 solutions for their own interest. 530 Since GMPLS is based on RSVP-TE and CR-LDP, it mandates a 531 downstream-on-demand label allocation and distribution, with an 532 ingress initiated ordered control. Liberal label retention is 533 normally used, but conservative label retention mode could also be 534 used. Furthermore, there is no restriction on the label allocation 535 strategy, it can be request/signaling driven (obvious for circuit 536 switching technologies), traffic/data driven, or even topology 537 driven. There is also no restriction on the route selection; 538 explicit routing is normally used (strict or loose) but hop-by-hop 539 routing could be used as well. 541 GMPLS also extends two traditional intra-domain link-state routing 542 protocols already extended for TE purposes, i.e. OSPF-TE and IS-IS- 543 TE. However, if explicit (source) routing is used, the routing 544 algorithms used by these protocols no longer need to be 545 standardized. Extensions for inter-domain routing (e.g. BGP) are for 546 further study. 548 The use of technologies like DWDM (Dense Wavelength Division 549 Multiplexing) implies that we can now have a very large number of 550 parallel links between two directly adjacent nodes (hundreds of 551 wavelengths, or even thousands of wavelengths if multiple fibers are 552 used). Such a large number of links was not originally considered 553 for an IP or MPLS control plane, although it could be done. Some 554 slight adaptations of that control plane are thus required if we 555 want to better reuse it in the GMPLS context. 557 For instance, the traditional IP routing model assumes the 558 establishment of a routing adjacency over each link connecting two 559 adjacent nodes. Having such a large number of adjacencies does not 560 scale well. Each node needs to maintain each of its adjacencies one 561 by one, and link state routing information must be flooded 562 throughout the network. 564 To solve this issue the concept of link bundling was introduced. 565 Moreover, the manual configuration and control of these links, even 567 E. Mannie et. al. Internet-Draft February 2003 11 568 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 570 if they are unnumbered, becomes impractical. The Link Management 571 Protocol (LMP) was specified to solve these issues. 573 LMP runs between data plane adjacent nodes and is used to manage TE 574 links. Specifically, LMP provides mechanisms to maintain control 575 channel connectivity (IP Control Channel Maintenance), verify the 576 physical connectivity of the data-bearing links (Link Verification), 577 correlate the link property information (Link Property Correlation), 578 and manage link failures (Fault Localization and Fault 579 Notification). A unique feature of LMP is that it is able to 580 localize faults in both opaque and transparent networks (i.e. 581 independent of the encoding scheme and bit rate used for the data). 583 LMP is defined in the context of GMPLS, but is specified 584 independently of the GMPLS signaling specification since it is a 585 local protocol running between data-plane adjacent nodes. As a 586 result, LMP can be used in other contexts with non-GMPLS signaling 587 protocols. 589 The MPLS signaling and routing protocols require at least one bi- 590 directional control channel to communicate even if two adjacent 591 nodes are connected by unidirectional links. Several control 592 channels can be used. LMP can be used to establish, maintain and 593 manage these control channels. 595 GMPLS does not specify how these control channels must be 596 implemented, but GMPLS requires IP to transport the signaling and 597 routing protocols over them. Control channels can be either in-band 598 or out-of-band, and several solutions can be used to carry IP. Note 599 also that one type of LMP message (the Test message) is used in-band 600 in the data plane and may not be transported over IP, but this is a 601 particular case, needed to verify connectivity in the data plane. 603 3.4. GMPLS Key Extensions to MPLS-TE 605 Some key extensions brought by GMPLS to MPLS-TE are highlighted in 606 the following. Some of them are key advantages of GMPLS to control 607 TDM, LSC and FSC layers. 609 - In MPLS-TE, links traversed by an LSP can include an intermix of 610 links with heterogeneous label encoding (e.g. links between routers, 611 links between routers and ATM-LSRs, and links between ATM-LSRs. 612 GMPLS extends this by including links where the label is encoded as 613 a time slot, or a wavelength, or a position in the real world 614 physical space. 616 - In MPLS-TE, an LSP that carries IP has to start and end on a 617 router. GMPLS extends this by requiring an LSP to start and end on 618 similar type of LSR. 620 - The type of a payload that can be carried in GMPLS by an LSP is 621 extended to allow such payloads as SONET/SDH, G.709, 1 or 10Gb 622 Ethernet, etc. 624 E. Mannie et. al. Internet-Draft February 2003 12 625 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 627 - The use of Forwarding Adjacencies (FA), provides a mechanism that 628 can improve bandwidth utilization, when bandwidth allocation can be 629 performed only in discrete units, as well as a mechanism to 630 aggregate forwarding state, thus allowing the number of required 631 labels to be reduced. 633 - GMPLS allows for a label to be suggested by an upstream node to 634 reduce the setup latency. This suggestion may be overridden by a 635 downstream node but, in some cases, at the cost of higher LSP setup 636 time. 638 - GMPLS extends on the notion of restricting the range of labels 639 that may be selected by a downstream node. In GMPLS, an upstream 640 node may restrict the labels for an LSP along either a single hop or 641 along the entire LSP path. This feature is useful in photonic 642 networks where wavelength conversion may not be available. 644 - While traditional TE-based (and even LDP-based) LSPs are 645 unidirectional, GMPLS supports the establishment of bi-directional 646 LSPs. 648 - GMPLS supports the termination of an LSP on a specific egress 649 port, i.e. the port selection at the destination side. 651 - GMPLS with RSVP-TE supports an RSVP specific mechanism for rapid 652 failure notification. 654 Note also some other key differences between MPLS-TE and GMPLS: 656 - For TDM, LSC and FSC interfaces, bandwidth allocation for an LSP 657 can be performed only in discrete units. 659 - It is expected to have (much) fewer labels on TDM, LSC or FSC 660 links than on PSC or L2SC links, because the former are physical 661 labels instead of logical labels. 663 4. Routing and addressing model 665 GMPLS is based on the IP routing and addressing models. This assumes 666 that IPv4 and/or IPv6 addresses are used to identify interfaces and 667 that traditional (distributed) IP routing protocols are also reused. 668 Indeed, the discovery of the topology and the resource state of all 669 links in a routing domain is achieved via these routing protocols. 671 Since control and data planes are de-coupled in GMPLS, control-plane 672 neighbors (i.e. IGP-learnt neighbors) may not be anymore data-plane 673 neighbors, hence mechanisms like LMP are needed to associate TE 674 links with neighboring nodes. 676 IP addresses are not used only to identify interfaces of IP hosts 677 and routers, but more generally to identify any PSC and non-PSC 678 interfaces. Similarly, IP routing protocols are used to find routes 679 for IP datagrams with a SPF algorithm, and are also used to find 680 routes for non-PSC circuits by using a CSPF algorithm. 682 E. Mannie et. al. Internet-Draft February 2003 13 683 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 685 However, some additional mechanisms are needed to increase the 686 scalability of these models and to deal with specific traffic 687 engineering requirements of non-PSC layers. These mechanisms will be 688 introduced in the following. 690 Re-using existing IP routing protocols allows for non-PSC layers to 691 take advantages of all the valuable developments that took place 692 since years for IP routing, in particular in the context of intra- 693 domain routing (link-state routing) and inter-domain routing (policy 694 routing). 696 In an overlay model, each particular non-PSC layer can be seen as a 697 set of Autonomous Systems (ASs) interconnected in an arbitrary way. 698 Similarly to the traditional IP routing, each AS is managed by a 699 single administrative authority. For instance, an AS can be an 700 SDH/SONET network operated by a given carrier. The set of 701 interconnected ASs being an SDH/SONET Internetwork. 703 Exchange of routing information between ASs can be done via an 704 inter-domain routing protocol like BGP-4. There is obviously a huge 705 value of re-using well-known policy routing facilities provided by 706 BGP in a non-PSC context. Extensions for BGP traffic engineering 707 (BGP-TE) in the context of non-PSC layers are left for further 708 study. 710 Each AS can be subdivided in different routing domains, and each can 711 run a different intra-domain routing protocol. In turn, each 712 routing-domain can be divided in areas. 714 A routing domain is made of GMPLS enabled nodes (i.e. a network 715 device including a GMPLS entity). These nodes can be either edge 716 nodes (i.e. hosts, ingress LSRs or egress LSRs), or internal LSRs. 717 An example of non-PSC host is an SDH/SONET Terminal Multiplexer 718 (TM). Another example is an SDH/SONET interface card within an IP 719 router or ATM switch. 721 Note that traffic engineering in the intra-domain requires the use 722 of link-state routing protocols like OSPF or IS-IS. 724 GMPLS defines extensions to these protocols. These extensions are 725 needed to disseminate specific TDM, LSC and FSC static and dynamic 726 characteristics related to nodes and links. The current focus is on 727 intra-area traffic engineering. However, inter-area traffic 728 engineering is also under investigation. 730 4.1. Addressing of PSC and non-PSC layers 732 The fact that IPv4 and/or IPv6 addresses are used doesn't imply at 733 all that they should be allocated in the same addressing space than 734 public IPv4 and/or IPv6 addresses used for the Internet. Private IP 735 addresses can be used if they don't require to be exchanged with any 736 other operator, public IP addresses are otherwise required. Of 738 E. Mannie et. al. Internet-Draft February 2003 14 739 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 741 course, if an integrated model is used, two layers could share the 742 same addressing space. 744 Note that there is a benefit of using public IPv4 and/or IPv6 745 Internet addresses for non-PSC layers if an integrated model with 746 the IP layer is foreseen. 748 If we consider the scalability enhancements proposed in the next 749 section, the IPv4 (32 bits) and the IPv6 (128 bits) addressing 750 spaces are both more than sufficient to accommodate any non-PSC 751 layer. We can reasonably expect to have much less non-PSC devices 752 (e.g. SDH/SONET nodes) than we have today IP hosts and routers. 754 4.2. GMPLS scalability enhancements 756 TDM, LSC and FSC layers introduce new constraints on the IP 757 addressing and routing models since several hundreds of parallel 758 physical links (e.g. wavelengths) can now connect two nodes. Most of 759 the carriers already have today several tens of wavelengths per 760 fiber between two nodes. New generation of DWDM systems will allow 761 several hundreds of wavelengths per fiber. 763 It becomes rather impractical to associate an IP address with each 764 end of each physical link, to represent each link as a separate 765 routing adjacency, and to advertise and to maintain link states for 766 each of these links. For that purpose, GMPLS enhances the MPLS 767 routing and addressing models to increase their scalability. 769 Two optional mechanisms can be used to increase the scalability of 770 the addressing and the routing: unnumbered links and link bundling. 771 These two mechanisms can also be combined. They require extensions 772 to signaling (RSVP-TE and CR-LDP) and routing (OSPF-TE and IS-IS-TE) 773 protocols. 775 4.3. TE Extensions to IP routing protocols 777 Traditionally, a TE link is advertised as an adjunct to a "regular" 778 OSPF or IS-IS link, i.e., an adjacency is brought up on the link, 779 and when the link is up, both the regular IGP properties of the link 780 (basically, the SPF metric) and the TE properties of the link are 781 then advertised. 783 However, GMPLS challenges this notion in three ways: 785 - First, links that are non-PSC may yet have TE properties; however, 786 an OSPF adjacency could not be brought up directly on such links. 788 - Second, an LSP can be advertised as a point-to-point TE link in 789 the routing protocol, i.e. as a Forwarding Adjacency (FA); thus, an 790 advertised TE link need no longer be between two OSPF direct 791 neighbors. Forwarding Adjacencies (FA) are further described in a 792 separate section. 794 E. Mannie et. al. Internet-Draft February 2003 15 795 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 797 - Third, a number of links may be advertised as a single TE link 798 (e.g. for improved scalability), so again, there is no longer a one- 799 to-one association of a regular adjacency and a TE link. 801 Thus we have a more general notion of a TE link. A TE link is a 802 logical link that has TE properties, some of which may be configured 803 on the advertising LSR, others which may be obtained from other LSRs 804 by means of some protocol, and yet others which may be deduced from 805 the component(s) of the TE link. 807 An important TE property of a TE link is related to the bandwidth 808 accounting for that link. GMPLS will define different accounting 809 rules for different non-PSC layers. Generic bandwidth attributes are 810 however defined by the TE routing extensions and by GMPLS, such as 811 the unreserved bandwidth, the maximum reservable bandwidth, the 812 maximum LSP bandwidth. 814 It is expected in a dynamic environment to have frequent changes of 815 bandwidth accounting information. A flexible policy for triggering 816 link state updates based on bandwidth thresholds and link-dampening 817 mechanism can be implemented. 819 TE properties associated with a link should also capture protection 820 and restoration related characteristics. For instance, shared 821 protection can be elegantly combined with bundling. Protection and 822 restoration are mainly generic mechanisms also applicable to MPLS. 823 It is expected that they will first be developed for MPLS and later 824 on generalized to GMPLS. 826 A TE link between a pair of LSRs doesn't imply the existence of an 827 IGP adjacency between these LSRs. A TE link must also have some 828 means by which the advertising LSR can know of its liveness (e.g. by 829 using LMP hellos). When an LSR knows that a TE link is up, and can 830 determine the TE link's TE properties, the LSR may then advertise 831 that link to its GMPLS enhanced OSPF or IS-IS neighbors using the TE 832 objects/TLVs. We call the interfaces over which GMPLS enhanced OSPF 833 or ISIS adjacencies are established "control channels". 835 5. Unnumbered links 837 Unnumbered links (or interfaces) are links (or interfaces) that do 838 not have IP addresses. Using such links involves two capabilities: 839 the ability to specify unnumbered links in MPLS TE signaling, and 840 the ability to carry (TE) information about unnumbered links in IGP 841 TE extensions of ISIS-TE and OSPF-TE. 843 A. The ability to specify unnumbered links in MPLS TE signaling 844 requires extensions to RSVP-TE and CR-LDP. The MPLS-TE signaling 845 doesn't provide support for unnumbered links, because it doesn�t 846 provide a way to indicate an unnumbered link in its Explicit Route 847 Object/TLV and in its Record Route Object (there is no such TLV 848 for CR-LDP). GMPLS defines simple extensions to indicate an 849 unnumbered link in these two Objects/TLVs, using a new Unnumbered 850 Interface ID sub-object/sub-TLV. 852 E. Mannie et. al. Internet-Draft February 2003 16 853 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 855 Since unnumbered links are not identified by an IP address, then 856 for the purpose of MPLS TE each end need some other identifier, 857 local to the LSR to which the link belongs. LSRs at the two end 858 points of an unnumbered link exchange with each other the 859 identifiers they assign to the link. Exchanging the identifiers 860 may be accomplished by configuration, by means of a protocol such 861 as LMP ([LMP]), by means of RSVP/CR-LDP (especially in the case 862 where a link is a Forwarding Adjacency, see below), or by means of 863 IS-IS or OSPF extensions ([ISIS-GMPLS], [OSPF-GMPLS]). 865 Consider an (unnumbered) link between LSRs A and B. LSR A chooses 866 an identifier for that link. So is LSR B. From A's perspective we 867 refer to the identifier that A assigned to the link as the "link 868 local identifier" (or just "local identifier"), and to the 869 identifier that B assigned to the link as the "link remote 870 identifier" (or just "remote identifier"). Likewise, from B's 871 perspective the identifier that B assigned to the link is the 872 local identifier, and the identifier that A assigned to the link 873 is the remote identifier. 875 The new Unnumbered Interface ID sub-object/sub-TLV for the ER 876 Object/TLV contains the Router ID of the LSR at the upstream end 877 of the unnumbered link and the outgoing interface identifier or 878 the link local identifier with respect to that upstream LSR. 880 The new Unnumbered Interface ID sub-object for the RR Object 881 contains the outgoing interface identifier with respect to the LSR 882 that adds it in the RR Object. 884 B. The ability to carry (TE) information about unnumbered links in 885 IGP TE extensions requires new sub-TLVs for the extended IS 886 reachability TLV defined in ISIS-TE and for the TE LSA (which is 887 an opaque LSA) defined in OSPF-TE. A Link Local Identifier sub-TLV 888 and a Link Remote Identifier sub-TLV are defined. 890 5.1. Unnumbered Forwarding Adjacencies 892 If an LSR that originates an LSP advertises this LSP as an 893 unnumbered FA in IS-IS or OSPF, or the LSR uses this FA as an 894 unnumbered component link of a bundled link, the LSR must allocate 895 an Interface ID to that FA. If the LSP is bi-directional, the tail 896 end does the same and allocates an Interface ID to the reverse FA. 898 Signaling has been enhanced to carry the Interface ID of a FA in the 899 new LSP Tunnel Interface ID object/TLV. This object/TLV contains the 900 Router ID of the LSR that generates it, and the Interface ID. It is 901 called the Forward Interface ID when it appears in a Path/REQUEST 902 message, and it is called the Reverse Interface ID when it appears 903 in the Resv/MAPPING message. 905 6. Link bundling 907 E. Mannie et. al. Internet-Draft February 2003 17 908 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 910 The concept of link bundling is essential in certain networks 911 employing the GMPLS control plane as is defined in [BUNDLE]. A 912 typical example is an optical meshed network where adjacent optical 913 cross-connects (LSRs) are connected by several hundreds of parallel 914 wavelengths. In this network, consider the application of link state 915 routing protocols, like OSPF or IS-IS, with suitable extensions for 916 resource discovery and dynamic route computation. Each wavelength 917 must be advertised separately in order to be used, except if link 918 bundling is used. 920 When a pair of LSRs is connected by multiple links, it is possible 921 to advertise several (or all) of these links as a single link into 922 OSPF and/or IS-IS. This process is called link bundling, or just 923 bundling. The resulting logical link is called a bundled link as its 924 physical links are called component links (and are identified by 925 interface indexes). 927 It results that a combination of three identifiers ((bundled) link 928 identifier, component link identifier, label) is sufficient to 929 unambiguously identify the appropriate resources used by an LSP. 931 The purpose of link bundling is to improve routing scalability by 932 reducing the amount of information that has to be handled by OSPF 933 and/or IS-IS. This reduction is accomplished by performing 934 information aggregation/abstraction. As with any other information 935 aggregation/abstraction, this results in losing some of the 936 information. To limit the amount of losses one need to restrict the 937 type of the information that can be aggregated/abstracted. 939 6.1. Restrictions on bundling 941 The following restrictions are required for bundling links. All 942 component links in a bundle must begin and end on the same pair of 943 LSRs; and share some common characteristics or properties defined in 944 [OSPF-TE] and [ISIS-TE], i.e. they must have the same: 946 - Link Type (i.e. point-to-point or multi-access), 947 - TE Metric (i.e. an administrative cost), 948 - Set of Resource Classes at each end of the links (i.e. colors). 950 Note that an FA may also be a component link. In fact, a bundle can 951 consist of a mix of point-to-point links and FAs, but all sharing 952 some common properties. 954 6.2. Routing considerations for bundling 956 A bundled link is just another kind of TE link such as those defined 957 by [GMPLS-ROUTING]. The liveness of the bundled link is determined 958 by the liveness of each its component links, a bundled link is alive 959 when at least one of its component links is alive. The liveness of a 960 component link can be determined by any of several means: IS-IS or 961 OSPF hellos over the component link, or RSVP Hello (hop local), or 962 LMP hellos (link local), or from layer 1 or layer 2 indications. 964 E. Mannie et. al. Internet-Draft February 2003 18 965 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 967 Note that according to the RSVP-TE Tunnel specification the RSVP 968 Hello mechanism is intended to be used when notification of link 969 layer failures is not available and unnumbered links are not used, 970 or when the failure detection mechanisms provided by the link layer 971 are not sufficient for timely node failure detection. 973 Once a bundled link is determined to be alive, it can be advertised 974 as a TE link and the TE information can be flooded. If IS-IS/OSPF 975 hellos are run over the component links, IS-IS/OSPF flooding can be 976 restricted to just one of the component links. 978 Note that advertising a (bundled) TE link between a pair of LSRs 979 doesn't imply that there is an IGP adjacency between these LSRs that 980 is associated with just that link. In fact, in certain cases a TE 981 link between a pair of LSRs could be advertised even if there is no 982 IGP adjacency at all between the LSR (e.g. when the TE link is an 983 FA). 985 Forming a bundled link consist in aggregating the identical TE 986 parameters of each individual component link to produce aggregated 987 TE parameters. A TE link as defined by [GMPLS-ROUTING] has many 988 parameters, adequate aggregation rules must be defined for each one. 990 Some parameters can be sums of component characteristics such as the 991 unreserved bandwidth and the maximum reservable bandwidth. Bandwidth 992 information is an important part of a bundle advertisement and it 993 must be clearly defined since an abstraction is done. 995 A GMPLS node with bundled links must apply admission control on a 996 per-component link basis. 998 6.3. Signaling considerations 1000 Typically, an LSP's explicit route (e.g. contained in an explicit 1001 route TLV/Object) will choose the bundled link to be used for the 1002 LSP, but not the component link(s), since information about the 1003 bundled link is flooded, but information about the component links 1004 is not. 1006 The choice of the component link to use is always made by an 1007 upstream node. If the LSP is bidirectional, the upstream node 1008 chooses a component link in each direction. 1010 Three mechanisms for indicating this choice to the downstream node 1011 are possible. 1013 6.3.1. Mechanism 1: Implicit Indication 1015 This mechanism requires that each component link has a dedicated 1016 signaling channel (e.g. the link is a Sonet/SDH link using the DCC 1017 for in-band signaling). The upstream node tells the receiver which 1018 component link to use by sending the message over the chosen 1019 component link's dedicated signaling channel. Note that this 1020 signaling channel can be in-band or out-of-band. In this last case, 1022 E. Mannie et. al. Internet-Draft February 2003 19 1023 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1025 the association between the signaling channel and that component 1026 link need to be explicitly configured. 1028 6.3.2. Mechanism 2: Explicit Indication by Numbered Interface ID 1030 This mechanism requires that the component link has a unique remote 1031 IP address. The upstream node indicates the choice of the component 1032 link by including a new IF_ID RSVP_HOP object/IF_ID TLV carrying 1033 either an IPv4 or an IPv6 address in the Path/Label Request message 1034 [RSVP-TE-GMPLS] [CR-LDP-GMPLS]. For a bi-directional LSP, a 1035 component link is provided for each direction by the upstream node. 1037 This mechanism does not require each component link to have its own 1038 control channel. In fact, it doesn't even require the whole 1039 (bundled) link to have its own control channel. 1041 6.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID 1043 With this mechanism, each component link that is unnumbered is 1044 assigned a unique Interface Identifier (32 bits value). The upstream 1045 node indicates the choice of the component link by including a new 1046 IF_ID RSVP_HOP object/IF_ID TLV in the Path/Label Request message 1047 [RSVP-TE-GMPLS] [CR-LDP-GMPLS]. 1049 This object/TLV carries the component interface ID in the downstream 1050 direction for a unidirectional LSP, and in addition the component 1051 interface ID in the upstream direction for a bi-directional LSP. 1053 The two LSRs at each end of the bundled link exchange these 1054 identifiers. Exchanging the identifiers may be accomplished by 1055 configuration, by means of a protocol such as LMP (preferred 1056 solution), by means of RSVP/CR-LDP (especially in the case where a 1057 component link is a Forwarding Adjacency), or by means of IS-IS or 1058 OSPF extensions. 1060 This mechanism does not require each component link to have its own 1061 control channel. In fact, it doesn't even require the whole 1062 (bundled) link to have its own control channel. 1064 6.4. Unnumbered Bundled Link 1066 A bundled link may itself be numbered or unnumbered independent of 1067 whether the component links are numbered or not. This affects how 1068 the bundled link is advertised in IS-IS/OSPF, and the format of LSP 1069 EROs that traverse the bundled link. Furthermore, unnumbered 1070 Interface Identifiers for all unnumbered outgoing links of a given 1071 LSR (whether component links, Forwarding Adjacencies or bundled 1072 links) must be unique in the context of that LSR. 1074 6.5. Forming bundled links 1076 The generic rule for bundling component links is to place those 1077 links that are correlated in some manner in the same bundle. If 1078 links may be correlated based on multiple properties then the 1080 E. Mannie et. al. Internet-Draft February 2003 20 1081 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1083 bundling may be applied sequentially based on these properties. For 1084 instance, links may be first grouped based on the first property. 1085 Each of these groups may be then divided into smaller groups based 1086 on the second property and so on. The main principle followed in 1087 this process is that the properties of the resulting bundles should 1088 be concisely summarizable. Link bundling may be done automatically 1089 or by configuration. Automatic link bundling can apply bundling 1090 rules sequentially to produce bundles. 1092 For instance, the first property on which component links may be 1093 correlated could be the Interface Switching Capability [GMPLS- 1094 ROUTING], the second property could be the Encoding [GMPLS-ROUTING], 1095 the third property could be the Administrative Weight (cost), the 1096 fourth property could be the Resource Classes and finally links may 1097 be correlated based on other metrics such as SRLG (Shared Risk Link 1098 Groups). 1100 When routing an alternate path for protection purposes, the general 1101 principle followed is that the alternate path is not routed over any 1102 link belonging to an SRLG that some link in the primary path belongs 1103 to. Thus, the rule to be followed is to group links belonging to 1104 exactly the same set of SRLGs. 1106 This type of sequential sub-division may result in a number of 1107 bundles between two adjacent nodes. In practice, however, the link 1108 properties may not be very heterogeneous among component links 1109 between two adjacent nodes. Thus, the number of bundles in practice 1110 may not be large. 1112 7. Relationship with the UNI 1114 The interface between an edge GMPLS node and a GMPLS LSR on the 1115 network side may be referred to as a User to Network Interface 1116 (UNI), while the interface between two network side LSRs may be 1117 referred to as a Network to Network Interface (NNI). 1119 GMPLS does not specify separately a UNI and an NNI. Edge nodes are 1120 connected to LSRs on the network side, and these LSRs are in turn 1121 connected between them. Of course, the behavior of an edge node is 1122 not exactly the same as the behavior of an LSR on the network side. 1123 Note also, that an edge node may run a routing protocol, however it 1124 is expected that in most of the cases it will not (see also section 1125 7.2 and the section about signaling with an explicit route). 1127 Conceptually, a difference between UNI and NNI make sense either if 1128 both interface uses completely different protocols, or if they use 1129 the same protocols but with some outstanding differences. In the 1130 first case, separate protocols are often defined successively, with 1131 more or less success. 1133 The GMPLS approach consisted in building a consistent model from day 1134 one, considering both the UNI and NNI interfaces at the same time. 1135 For that purpose a very few specific UNI particularities have been 1136 ignored in a first time. GMPLS has been enhanced to support such 1138 E. Mannie et. al. Internet-Draft February 2003 21 1139 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1141 particularities at the UNI by some other standardization bodies (see 1142 hereafter). 1144 7.1. Relationship with the OIF UNI 1146 This section is only given for reference to the OIF work related to 1147 GMPLS. The current OIF UNI specification [OIF-UNI] defines an 1148 interface between a client SDH/SONET equipment and an SDH/SONET 1149 network, each belonging to a distinct administrative authority. It 1150 is designed for an overlay model. The OIF UNI defines additional 1151 mechanisms on the top of GMPLS for the UNI. 1153 For instance, the OIF service discovery procedure is a precursor to 1154 obtaining UNI services. Service discovery allows a client to 1155 determine the static parameters of the interconnection with the 1156 network, including the UNI signaling protocol, the type of 1157 concatenation, the transparency level as well as the type of 1158 diversity (node, link, SRLG) supported by the network. 1160 Since the current OIF UNI interface does not cover photonic 1161 networks, G.709 Digital Wrapper, etc, it is from that perspective a 1162 subset of the GMPLS Architecture at the UNI. 1164 7.2. Reachability across the UNI 1166 This section discusses the selection of an explicit route by an edge 1167 node. The selection of the first LSR by an edge node connected to 1168 multiple LSRs is part of that problem. 1170 An edge node (host or LSR) can participate more or less deeply in 1171 the GMPLS routing. Four different routing models can be supported at 1172 the UNI: configuration based, partial peering, silent listening and 1173 full peering. 1175 - Configuration based: this routing model requires the manual or 1176 automatic configuration of an edge node with a list of neighbor LSRs 1177 sorted by preference order. Automatic configuration can be achieved 1178 using DHCP for instance. No routing information is exchanged at the 1179 UNI, except maybe the ordered list of LSRs. The only routing 1180 information used by the edge node is that list. The edge node sends 1181 by default an LSP request to the preferred LSR. ICMP redirects could 1182 be send by this LSR to redirect some LSP requests to another LSR 1183 connected to the edge node. GMPLS does not preclude that model. 1185 - Partial peering: limited routing information (mainly reachability) 1186 can be exchanged across the UNI using some extensions in the 1187 signaling plane. The reachability information exchanged at the UNI 1188 may be used to initiate edge node specific routing decision over the 1189 network. GMPLS does not have any capability to support this model 1190 today. 1192 - Silent listening: the edge node can silently listen to routing 1193 protocols and take routing decisions based on the information 1194 obtained. An edge node receives the full routing information, 1196 E. Mannie et. al. Internet-Draft February 2003 22 1197 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1199 including traffic engineering extensions. One LSR should forward 1200 transparently all routing pdus to the edge node. An edge node can 1201 now compute a complete explicit route taking into consideration all 1202 the end-to-end routing information. GMPLS does not preclude this 1203 model. 1205 - Full peering: In addition to silent listening, the edge node 1206 participates within the routing, establish adjacencies with its 1207 neighbors and advertises LSAs. This is useful only if there are 1208 benefits for edge nodes to advertise themselves traffic engineering 1209 information. GMPLS does not preclude this model. 1211 8. Link Management 1213 In the context of GMPLS, a pair of nodes (e.g., a photonic switch) 1214 may be connected by tens of fibers, and each fiber may be used to 1215 transmit hundreds of wavelengths if DWDM is used. Multiple fibers 1216 and/or multiple wavelengths may also be combined into one or more 1217 bundled links for routing purposes. Furthermore, to enable 1218 communication between nodes for routing, signaling, and link 1219 management, control channels must be established between a node 1220 pair. 1222 Link management is a collection of useful procedures between 1223 adjacent nodes that provide local services such as control channel 1224 management, link connectivity verification, link property 1225 correlation, and fault management. The Link Management Protocol 1226 (LMP) has been defined to fulfill these operations. LMP was 1227 initiated in the context of GMPLS but is a generic toolbox that can 1228 be also used in other contexts. 1230 Control channel management and link property correlation are 1231 mandatory procedures of LMP. Link connectivity verification and 1232 fault management are optional procedures. 1234 8.1. Control channel and control channel management 1236 LMP control channel management is used to establish and maintain 1237 control channels between nodes. Control channels exist independently 1238 of TE links, and can be used to exchange MPLS control-plane 1239 information such as signaling, routing, and link management 1240 information. 1242 An "LMP adjacency" is formed between two nodes that support the same 1243 LMP capabilities. Multiple control channels may be active 1244 simultaneously for each adjacency. A control channel can be either 1245 explicitly configured or automatically selected, however, LMP 1246 currently assume that control channels are explicitly configured 1247 while the configuration of the control channel capabilities can be 1248 dynamically negotiated. 1250 For the purposes of LMP, the exact implementation of the control 1251 channel is left unspecified. The control channel(s) between two 1252 adjacent nodes is no longer required to use the same physical medium 1254 E. Mannie et. al. Internet-Draft February 2003 23 1255 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1257 as the data-bearing links between those nodes. For example, a 1258 control channel could use a separate wavelength or fiber, an 1259 Ethernet link, or an IP tunnel through a separate management 1260 network. 1262 A consequence of allowing the control channel(s) between two nodes 1263 to be physically diverse from the associated data-bearing links is 1264 that the health of a control channel does not necessarily correlate 1265 to the health of the data-bearing links, and vice-versa. Therefore, 1266 new mechanisms have been developed in LMP to manage links, both in 1267 terms of link provisioning and fault isolation. 1269 LMP does not specify the signaling transport mechanism used in the 1270 control channel, however it states that messages transported over a 1271 control channel must be IP encoded. Furthermore, since the messages 1272 are IP encoded, the link level encoding is not part of LMP. A 32-bit 1273 non-zero integer control channel identifier (CCId) is assigned to 1274 each direction of a control channel. 1276 Each control channel individually negotiates its control channel 1277 parameters and maintains connectivity using a fast Hello protocol. 1278 The latter is required if lower-level mechanisms are not available 1279 to detect link failures. 1281 The Hello protocol of LMP is intended to be a lightweight keep-alive 1282 mechanism that will react to control channel failures rapidly so 1283 that IGP Hellos are not lost and the associated link-state 1284 adjacencies are not removed unnecessarily. 1286 The Hello protocol consists of two phases: a negotiation phase and a 1287 keep-alive phase. The negotiation phase allows negotiation of some 1288 basic Hello protocol parameters, like the Hello frequency. The keep- 1289 alive phase consists of a fast lightweight bi-directional Hello 1290 message exchange. 1292 If a group of control channels share a common node pair and support 1293 the same LMP capabilities, then LMP control channel messages (except 1294 Configuration messages, and Hello) may be transmitted over any of 1295 the active control channels without coordination between the local 1296 and remote nodes. 1298 For LMP, it is essential that at least one control channel is always 1299 available. In the event of a control channel failure, it may be 1300 possible to use an alternate active control channel without 1301 coordination. 1303 8.2. Link property correlation 1305 As part of LMP, a link property correlation exchange is defined. 1306 The exchange is used to aggregate multiple data-bearing links (i.e. 1307 component links) into a bundled link and exchange, correlate, or 1308 change TE link parameters. The link property correlation exchange 1309 may be done at any time a link is up and not in the Verification 1310 process (see next section). 1312 E. Mannie et. al. Internet-Draft February 2003 24 1313 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1315 It allows for instance to add component links to a link bundle, 1316 change a link's protection mechanism, change port identifiers, or 1317 change component identifiers in a bundle. This mechanism is 1318 supported by an exchange of link summary messages. 1320 8.3. Link connectivity verification 1322 Link connectivity verification is an optional procedure that may be 1323 used to verify the physical connectivity of data-bearing links as 1324 well as to exchange the link identifiers that are used in the GMPLS 1325 signaling. 1327 The use of this procedure is negotiated as part of the configuration 1328 exchange that take place during the negotiation phase of the Hello 1329 protocol. This procedure should be done initially when a data- 1330 bearing link is first established, and subsequently, on a periodic 1331 basis for all unallocated (free) data-bearing links. 1333 The verification procedure consists of sending Test messages in-band 1334 over the data-bearing links. This requires that the unallocated 1335 links must be opaque; however, multiple degrees of opaqueness (e.g., 1336 examining overhead bytes, terminating the payload, etc.), and hence 1337 different mechanisms to transport the Test messages, are specified. 1338 Note that the Test message is the only LMP message that is 1339 transmitted over the link, and that Hello messages continue to be 1340 exchanged over the control channel during the link verification 1341 process. Data-bearing links are tested in the transmit direction as 1342 they are unidirectional. As such, it is possible for LMP neighboring 1343 nodes to exchange the Test messages simultaneously in both 1344 directions. 1346 To initiate the link verification procedure, a node must first 1347 notify the adjacent node that it will begin sending Test messages 1348 over a particular data-bearing link, or over the component links of 1349 a particular bundled link. The node must also indicate the number of 1350 data-bearing links that are to be verified; the interval at which 1351 the test messages will be sent; the encoding scheme, the transport 1352 mechanism that are supported, data rate for Test messages; and, in 1353 the case where the data-bearing links correspond to fibers, the 1354 wavelength over which the Test messages will be transmitted. 1355 Furthermore, the local and remote bundled link identifiers are 1356 transmitted at this time to perform the component link association 1357 with the bundled link identifiers. 1359 8.4. Fault management 1361 Fault management is an important requirement from the operational 1362 point of view. Fault management includes usually: fault detection, 1363 fault localization and fault notification. When a failure occurs and 1364 is detected (fault detection), an operator needs to know exactly 1365 where it happened (fault localization) and a source node may need to 1366 be notified in order to take some actions (fault notification). 1368 E. Mannie et. al. Internet-Draft February 2003 25 1369 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1371 Note that fault localization can also be used to support some 1372 specific local protection/restoration mechanisms. 1374 In new technologies such as transparent photonic switching currently 1375 no method is defined to locate a fault, and the mechanism by which 1376 the fault information is propagated must be sent "out of band" (via 1377 the control plane). 1379 LMP provides a fault localization procedure that can be used to 1380 rapidly localize link failures, by notifying a fault up to the node 1381 upstream of that fault (i.e. through a fault notification 1382 procedure). 1384 A downstream LMP neighbor that detects data link failures will send 1385 an LMP message to its upstream neighbor notifying it of the failure. 1386 When an upstream node receives a failure notification, it can 1387 correlate the failure with the corresponding input ports to 1388 determine if the failure is between the two nodes. Once the failure 1389 has been localized, the signaling protocols can be used to initiate 1390 link or path protection/restoration procedures. 1392 8.5 LMP for DWDM Optical Line Systems (OLSs) 1394 In an all-optical environment, LMP focuses on peer communications 1395 (e.g. OXC-to-OXC). A great deal of information about a link between 1396 two OXCs is known by the OLS (Optical Line System or WDM Terminal 1397 multiplexer). Exposing this information to the control plane can 1398 improve network usability by further reducing required manual 1399 configuration and also by greatly enhancing fault detection and 1400 recovery. 1402 LMP-WDM [LMP-WDM] defines extensions to LMP for use between and OXC 1403 and an OLS. These extensions are intended to satisfy the Optical 1404 Link Interface Requirements described in [OLI-REQ]. 1406 Fault detection is particularly an issue when the network is using 1407 all-optical photonic switches (PXC). Once a connection is 1408 established, PXCs have only limited visibility into the health of 1409 the connection. Even though the PXC is all-optical, long-haul OLSs 1410 typically terminate channels electrically and regenerate them 1411 optically, which presents an opportunity to monitor the health of a 1412 channel between PXCs. LMP-WDM can then be used by the OLS to provide 1413 this information to the PXC. 1415 In addition to the link information known to the OLS that is 1416 exchanged through LMP-WDM, some information known to the OXC may 1417 also be exchanged with the OLS through LMP-WDM. This information is 1418 useful for alarm management and link monitoring (e.g. trace 1419 monitoring). Alarm management is important because the 1420 administrative state of a connection, known to the OXC (e.g. this 1421 information may be learned through the Admin Status object of GMPLS 1422 signaling [GMPLS]), can be used to suppress spurious alarms. For 1423 example, the OXC may know that a connection is "up", "down", in a 1424 "testing" mode, or being deleted ("deletion-in-progress"). The OXC 1426 E. Mannie et. al. Internet-Draft February 2003 26 1427 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1429 can use this information to inhibit alarm reporting from the OLS 1430 when a connection is "down", "testing", or being deleted. 1432 It is important to note that an OXC may peer with one or more OLSs 1433 and an OLS may peer with one or more OXCs. Although there are many 1434 similarities between an OXC-OXC LMP session and an OXC-OLS LMP 1435 session, particularly for control management and link verification, 1436 there are some differences as well. These differences can primarily 1437 be attributed to the nature of an OXC-OLS link, and the purpose of 1438 OXC-OLS LMP sessions. The OXC-OXC links can be used to provide the 1439 basis for GMPLS signaling and routing at the optical layer. The 1440 information exchanged over LMP-WDM sessions is used to augment 1441 knowledge about the links between OXCs. 1443 In order for the information exchanged over the OXC-OLS LMP sessions 1444 to be used by the OXC-OXC session, the information must be 1445 coordinated by the OXC. However, the OXC-OXC and OXC-OLS LMP 1446 sessions are run independently and must be maintained separately. 1447 One critical requirement when running an OXC-OLS LMP session is the 1448 ability of the OLS to make a data link transparent when not doing 1449 the verification procedure. This is because the same data link may 1450 be verified between OXC-OLS and between OXC-OXC. The verification 1451 procedure of LMP is used to coordinate the Test procedure (and hence 1452 the transparency/opaqueness of the data links). To maintain 1453 independence between the sessions, it must be possible for the LMP 1454 sessions to come up in any order. In particular, it must be possible 1455 for an OXC-OXC LMP session to come up without an OXC-OLS LMP session 1456 being brought up, and vice-versa. 1458 9. Generalized Signaling 1460 The GMPLS signaling extends certain base functions of the RSVP-TE 1461 and CR-LDP signaling and, in some cases, adds functionality. These 1462 changes and additions impact basic LSP properties, how labels are 1463 requested and communicated, the unidirectional nature of LSPs, how 1464 errors are propagated, and information provided for synchronizing 1465 the ingress and egress. 1467 The core GMPLS signaling specification is available in three parts: 1469 1. A signaling functional description [GMPLS-SIG]. 1470 2. RSVP-TE extensions [RSVP-TE-GMPLS]. 1471 3. CR-LDP extensions [CR-LDP-GMPLS]. 1473 In addition, independent parts are available per technology: 1475 1. GMPLS extensions for SONET and SDH control [SONETSDH-GMPLS]. 1476 2. GMPLS extensions for G.709 control [G709-GMPLS]. 1478 The following MPLS profile expressed in terms of MPLS features 1479 [RFC3031] applies to GMPLS: 1481 - Downstream-on-demand label allocation and distribution. 1482 - Ingress initiated ordered control. 1484 E. Mannie et. al. Internet-Draft February 2003 27 1485 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1487 - Liberal (typical), or conservative (could) label retention 1488 mode. 1489 - Request, traffic/data, or topology driven label allocation 1490 strategy. 1491 - Explicit routing (typical), or hop-by-hop routing. 1493 The GMPLS signaling defines the following new building blocks on the 1494 top of MPLS-TE: 1496 1. A new generic label request format. 1497 2. Labels for TDM, LSC and FSC interfaces, generically known as 1498 Generalized Label. 1499 3. Waveband switching support. 1500 4. Label suggestion by the upstream for optimization purposes 1501 (e.g. latency). 1502 5. Label restriction by the upstream to support some optical 1503 constraints. 1504 6. Bi-directional LSP establishment with contention 1505 resolution. 1506 7. Rapid failure notification extensions. 1507 8. Protection information currently focusing on link protection, 1508 plus primary and secondary LSP indication. 1509 9. Explicit routing with explicit label control for a fine 1510 degree of control. 1511 10. Specific traffic parameters per technology. 1512 11. LSP administrative status handling. 1514 These building blocks will be described in mode details in the 1515 following. A complete specification can be found in the 1516 corresponding documents. 1518 Note that GMPLS is highly generic and has many options. Only 1519 building blocks 1, 2 and 10 are mandatory, and only within the 1520 specific format that is needed. Typically building blocks 6 and 9 1521 should be implemented. Building blocks 3, 4, 5, 7, 8 and 11 are 1522 optional. 1524 A typical SDH/SONET switching network would implement building 1525 blocks: 1, 2 (the SDH/SONET label), 6, 9, 10 and 11. Building blocks 1526 7 and 8 are optional since the protection/restoration can be 1527 achieved using SDH/SONET overhead bytes. 1529 A typical wavelength switching network would implement building 1530 blocks: 1, 2 (the generic format), 4, 5, 6, 7, 8, 9 and 11. Building 1531 block 3 is only needed in the particular case of waveband switching. 1533 A typical fiber switching network would implement building blocks: 1534 1, 2 (the generic format), 6, 7, 8, 9 and 11. 1536 A typical MPLS-IP network would not implement any of these building 1537 blocks, since the absence of building block 1 would indicate regular 1538 MPLS-IP. Note however that building block 1 and 8 can be used to 1539 signal MPLS-IP as well. In that case, the MPLS-IP network can 1540 benefit from the link protection type (not available in CR-LDP, some 1542 E. Mannie et. al. Internet-Draft February 2003 28 1543 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1545 very basic form being available in RSVP-TE). Building block 2 is 1546 here a regular MPLS label and no new label format is required. 1548 GMPLS does not specify any profile for RSVP-TE and CR-LDP 1549 implementations that have to support GMPLS - except for what is 1550 directly related to GMPLS procedures. It is to the manufacturer to 1551 decide which are the optional elements and procedures of RSVP-TE and 1552 CR-LDP that need to be implemented. Some optional MPLS-TE elements 1553 can be useful for TDM, LSC and FSC layers, for instance the setup 1554 and holding priorities that are inherited from MPLS-TE. 1556 9.1. Overview: How to Request an LSP 1558 A TDM, LSC or FSC LSP is established by sending a PATH/Label Request 1559 message downstream to the destination. This message contains a 1560 Generalized Label Request with the type of LSP (i.e. the layer 1561 concerned), and its payload type. An Explicit Route (ERO) is also 1562 normally added to the message, but this can be added and/or 1563 completed by the first/default LSR. 1565 The requested bandwidth is encoded in the RSVP-TE SENDER_TSPEC 1566 object, or in the CR-LDP Traffic Parameters TLV. Specific parameters 1567 for a given technology are given in these traffic parameters, such 1568 as the type of signal, concatenation and/or transparency for a 1569 SDH/SONET LSP. For some other technology there be could just one 1570 bandwidth parameter indicating the bandwidth as a floating-point 1571 value. 1573 The requested local protection per link may be requested using the 1574 Protection Information Object/TLV. The end-to-end LSP protection is 1575 for further study and is introduced LSP protection/restoration 1576 section (see after). 1578 If the LSP is a bi-directional LSP, an Upstream Label is also 1579 specified in the Path/Label Request message. This label will be the 1580 one to use in the upstream direction. 1582 Additionally, a Suggested Label, a Label Set and a Waveband Label 1583 can also be included in the message. Other operations are defined in 1584 MPLS-TE. 1586 The downstream node will send back a Resv/Label Mapping message 1587 including one Generalized Label object/TLV that can contain several 1588 Generalized Labels. For instance, if a concatenated SDH/SONET signal 1589 is requested, several labels can be returned. 1591 In case of SDH/SONET virtual concatenation, a list of labels is 1592 returned. Each label identifying one element of the virtual 1593 concatenated signal. This limits virtual concatenation to remain 1594 within a single (component) link. 1596 In case of any type of SDH/SONET contiguous concatenation, only one 1597 label is returned. That label is the lowest signal of the contiguous 1598 concatenated signal (given an order specified in [SONETSDH-GMPLS]). 1600 E. Mannie et. al. Internet-Draft February 2003 29 1601 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1603 In case of SDH/SONET "multiplication", i.e. co-routing of circuits 1604 of the same type but without concatenation but all belonging to the 1605 same LSP, the explicit ordered list of all signals that take part in 1606 the LSP is returned. 1608 9.2. Generalized Label Request 1610 The Generalized Label Request is a new object/TLV to be added in an 1611 RSVP-TE Path message instead of the regular Label Request, or in a 1612 CR-LDP Request message in addition to the already existing TLVs. 1613 Only one label request can be used per message, so a single LSP can 1614 be requested at a time per signaling message. 1616 The Generalized Label Request gives three major characteristics 1617 (parameters) required to support the LSP being requested: the LSP 1618 Encoding Type, the Switching Type that must be used and the LSP 1619 payload type called Generalized PID (G-PID). 1621 The LSP Encoding Type indicates the encoding type that will be used 1622 with the data associated with the LSP, i.e. the type of technology 1623 being considered. For instance, it can be SDH, SONET, Ethernet, ANSI 1624 PDH, etc. It represents the nature of the LSP, and not the nature of 1625 the links that the LSP traverses. This is used hop-by-hop by each 1626 node. 1628 A link may support a set of encoding formats, where support means 1629 that a link is able to carry and switch a signal of one or more of 1630 these encoding formats. The Switching Type indicates then the type 1631 of switching that should be performed on a particular link for that 1632 LSP. This information is needed for links that advertise more than 1633 one type of switching capability. 1635 Nodes must verify that the type indicated in the Switching Type is 1636 supported on the corresponding incoming interface; otherwise the 1637 node must generate a notification message with a "Routing 1638 problem/Switching Type" indication. 1640 The LSP payload type (G-PID) identifies the payload carried by the 1641 LSP, i.e. an identifier of the client layer of that LSP. For some 1642 technologies it also indicates the mapping used by the client layer, 1643 e.g. byte synchronous mapping of E1. This must be interpreted 1644 according to the LSP encoding type of the LSP and is used by the 1645 nodes at the endpoints of the LSP to know to which client layer a 1646 request is destined, and in some cases by the penultimate hop. 1648 Other technology specific parameters are not transported in the 1649 Generalized Label Request but in technology specific traffic 1650 parameters as explained hereafter. Currently, two set of traffic 1651 parameters are defined, one for SONET/SDH and one for G.709. 1653 Note that it is expected than specific traffic parameters will be 1654 defined in the future for photonic (all optical) switching. 1656 E. Mannie et. al. Internet-Draft February 2003 30 1657 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1659 9.3. SONET/SDH Traffic Parameters 1661 The GMPLS SDH/SONET traffic parameters [SONETSDH-GMPLS] specify a 1662 powerful set of capabilities for SONET (ANSI T1.105) and SDH (ITU-T 1663 G.707). Optional non-standard capabilities are also available in 1664 [SONETSDH-EXT-GMPLS]. 1666 The first traffic parameter specifies the type of the elementary 1667 SONET/SDH signal that comprises the requested LSP, e.g. VC-11, VT6, 1668 VC-4, STS-3c, etc. Several transforms can then be applied 1669 successively on the elementary Signal to build the final signal 1670 being actually requested for the LSP. 1672 These transforms are the contiguous concatenation, the virtual 1673 concatenation, the transparency and the multiplication. Each one is 1674 optional. They must be applied strictly in the following order: 1676 - First, contiguous concatenation can be optionally applied on the 1677 Elementary Signal, resulting in a contiguously concatenated 1678 signal. 1679 - Second, virtual concatenation can be optionally applied either 1680 directly on the elementary Signal, or on the contiguously 1681 concatenated signal obtained from the previous phase. 1682 - Third, some transparency can be optionally specified when 1683 requesting a frame as signal rather than a container. Several 1684 transparency packages are defined. 1685 - Fourth, a multiplication can be optionally applied either directly 1686 on the elementary Signal, or on the contiguously concatenated 1687 signal obtained from the first phase, or on the virtually 1688 concatenated signal obtained from the second phase, or on these 1689 signals combined with some transparency. 1691 For RSVP-TE, the SONET/SDH traffic parameters are carried in a new 1692 SENDER_TSPEC and FLOWSPEC. The same format is used for both. There 1693 is no Adspec associated with the SENDER_TSPEC, either it is omitted 1694 or a default value is used. The content of the FLOWSPEC object 1695 received in a Resv message should be identical to the content of the 1696 SENDER_TSPEC of the corresponding Path message. In other words, the 1697 receiver is normally not allowed to change the values of the traffic 1698 parameters. However some level of negotiation may be achieved as 1699 explained in [SONETSDH-GMPLS] 1701 For CR-LDP, the SONET/SDH traffic parameters are simply carried in a 1702 new TLV. 1704 Note that a general discussion on SDH/SONET and GMPLS can be found 1705 in [SDH/SONET-GMPLS-FRAMEWORK]. 1707 9.4. G.709 Traffic Parameters 1709 Simply said, an ITU-T G.709 based network is decomposed in two major 1710 layers: an optical layer (i.e. made of wavelengths) and a digital 1711 layer. These two layers are divided into sub-layers and switching 1712 occurs at two specific sub-layers: at the OCh (Optical Channel) 1714 E. Mannie et. al. Internet-Draft February 2003 31 1715 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1717 optical layer and at the ODU (Optical channel Data Unit) electrical 1718 layer. The ODUk notation is used to denotes ODUs at different 1719 bandwidths. 1721 The GMPLS G.709 traffic parameters [G709-GMPLS] specify a powerful 1722 set of capabilities for ITU-T G.709 networks. 1724 The first traffic parameter specifies the type of the elementary 1725 G.709 signal that comprises the requested LSP, e.g. ODU1, OCh at 40 1726 Gbps, etc. Several transforms can then be applied successively on 1727 the elementary Signal to build the final signal being actually 1728 requested for the LSP. 1730 These transforms are the virtual concatenation and the 1731 multiplication. Each one of these transforms is optional. They must 1732 be applied strictly in the following order: 1734 - First, virtual concatenation can be optionally applied directly on 1735 the elementary Signal, 1736 - Second, a multiplication can be optionally applied, either 1737 directly on the elementary Signal, or on the virtually 1738 concatenated signal obtained from the first phase. 1740 Additional ODUk Multiplexing traffic parameters allow indicating an 1741 ODUk mapping (ODUj into ODUk) for an ODUk multiplexing LSP request. 1742 G.709 supports the following multiplexing capabilities: ODUj into 1743 ODUk (k > j); and ODU1 with ODU2 multiplexing into ODU3. 1745 For RSVP-TE, the SONET/SDH traffic parameters are carried in a new 1746 SENDER-TSPEC and FLOWSPEC. The same format is used for both. There 1747 is no Adspec associated with the SENDER_TSPEC, either it is omitted 1748 or a default value is used. The content of the FLOWSPEC object 1749 received in a Resv message should be identical to the content of the 1750 SENDER_TSPEC of the corresponding Path message. 1752 For CR-LDP, the SONET/SDH traffic parameters are simply carried in a 1753 new TLV. 1755 9.5. Bandwidth Encoding 1757 Some technologies that do not have (yet) specific traffic parameters 1758 just require a bandwidth encoding transported in a generic form. 1759 Bandwidth is carried in 32-bit number in IEEE floating-point format 1760 (the unit is bytes per second). Values are carried in a per protocol 1761 specific manner. For non-packet LSPs, it is useful to define 1762 discrete values to identify the bandwidth of the LSP. 1764 It should be noted that this bandwidth encoding do not apply to 1765 SONET/SDH and G.709, for which the traffic parameters fully define 1766 the requested SONET/SDH or G.709 signal. 1768 The bandwidth is coded in the Peak Data Rate field of Int-Serv 1769 objects for RSVP-TE in the SENDER_TSPEC and FLOWSPEC objects; and in 1771 E. Mannie et. al. Internet-Draft February 2003 32 1772 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1774 the Peak and Committed Data Rate fields of the CR-LDP Traffic 1775 Parameters TLV. 1777 9.6. Generalized Label 1779 The Generalized Label extends the traditional MPLS label by allowing 1780 the representation of not only labels that travel in-band with 1781 associated data packets, but also (virtual) labels that identify 1782 time-slots, wavelengths, or space division multiplexed positions. 1784 For example, the Generalized Label may identify (a) a single fiber 1785 in a bundle, (b) a single waveband within fiber, (c) a single 1786 wavelength within a waveband (or fiber), or (d) a set of time-slots 1787 within a wavelength (or fiber). It may also be a generic MPLS label, 1788 a Frame Relay label, or an ATM label (VCI/VPI). The format of a 1789 label can be as simple as an integer value such as a wavelength 1790 label or can be more elaborated such as an SDH/SONET or a G.709 1791 label. 1793 SDH and SONET define each a multiplexing structure. These 1794 multiplexing structures will be used as naming trees to create 1795 unique labels. Such a label will identify the exact position (times- 1796 lot(s)) of a signal in a multiplexing structure. Since the SONET 1797 multiplexing structure may be seen as a subset of the SDH 1798 multiplexing structure, the same format of label is used for SDH and 1799 SONET. A similar concept is applied to build a label at the G.709 1800 ODU layer. 1802 Since the nodes sending and receiving the Generalized Label know 1803 what kinds of link they are using, the Generalized Label does not 1804 identify its type, instead the nodes are expected to know from the 1805 context what type of label to expect. 1807 A Generalized Label only carries a single level of label, i.e. it is 1808 non-hierarchical. When multiple levels of labels (LSPs within LSPs) 1809 are required, each LSP must be established separately. 1811 9.7. Waveband Switching 1813 A special case of wavelength switching is waveband switching. A 1814 waveband represents a set of contiguous wavelengths, which can be 1815 switched together to a new waveband. For optimization reasons it may 1816 be desirable for a photonic cross-connect to optically switch 1817 multiple wavelengths as a unit. This may reduce the distortion on 1818 the individual wavelengths and may allow tighter separation of the 1819 individual wavelengths. A Waveband label is defined to support this 1820 special case. 1822 Waveband switching naturally introduces another level of label 1823 hierarchy and as such the waveband is treated the same way all other 1824 upper layer labels are treated. As far as the MPLS protocols are 1825 concerned there is little difference between a waveband label and a 1826 wavelength label except that semantically the waveband can be 1828 E. Mannie et. al. Internet-Draft February 2003 33 1829 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1831 subdivided into wavelengths whereas the wavelength can only be 1832 subdivided into time or statistically multiplexed labels. 1834 In the context of waveband switching, the generalized label used to 1835 indicate a waveband contains three fields, a waveband ID, a Start 1836 Label and an End Label. The Start and End Labels are channel 1837 identifiers from the sender perspective that identify respectively, 1838 the lowest value wavelength and the highest value wavelength making 1839 up the waveband. 1841 9.8. Label Suggestion by the Upstream 1843 GMPLS allows for a label to be optionally suggested by an upstream 1844 node. This suggestion may be overridden by a downstream node but in 1845 some cases, at the cost of higher LSP setup time. The suggested 1846 label is valuable when establishing LSPs through certain kinds of 1847 optical equipment where there may be a lengthy (in electrical terms) 1848 delay in configuring the switching fabric. For example micro mirrors 1849 may have to be elevated or moved, and this physical motion and 1850 subsequent damping takes time. If the labels and hence switching 1851 fabric are configured in the reverse direction (the norm) the 1852 MAPPING/Resv message may need to be delayed by 10's of milliseconds 1853 per hop in order to establish a usable forwarding path. It can be 1854 important for restoration purposes where alternate LSPs may need to 1855 be rapidly established as a result of network failures. 1857 9.9. Label Restriction by the Upstream 1859 An upstream node can optionally restrict (limit) the choice of label 1860 of a downstream node to a set of acceptable labels. Giving lists 1861 and/or ranges of inclusive (acceptable) or exclusive (unacceptable) 1862 labels in a Label Set provides this restriction. If not applied, all 1863 labels from the valid label range may be used. There are at least 1864 four cases where a label restriction is useful in the "optical" 1865 domain. 1867 1. The first case is where the end equipment is only capable of 1868 transmitting and receiving on a small specific set of 1869 wavelengths/bands. 1871 2. The second case is where there is a sequence of interfaces, which 1872 cannot support wavelength conversion and require the same wavelength 1873 be used end-to-end over a sequence of hops, or even an entire path. 1875 3. The third case is where it is desirable to limit the amount of 1876 wavelength conversion being performed to reduce the distortion on 1877 the optical signals. 1879 4. The last case is where two ends of a link support different sets 1880 of wavelengths. 1882 The receiver of a Label Set must restrict its choice of labels to 1883 one that is in the Label Set. A Label Set may be present across 1884 multiple hops. In this case each node generates it's own outgoing 1886 E. Mannie et. al. Internet-Draft February 2003 34 1887 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1889 Label Set, possibly based on the incoming Label Set and the node's 1890 hardware capabilities. This case is expected to be the norm for 1891 nodes with conversion incapable interfaces. 1893 9.10. Bi-directional LSP 1895 GMPLS allows establishment of bi-directional symmetric LSPs (not of 1896 asymmetric LSPs). A symmetric bi-directional LSP has the same 1897 traffic engineering requirements including fate sharing, protection 1898 and restoration, LSRs, and resource requirements (e.g. latency and 1899 jitter) in each direction. 1901 In the remainder of this section, the term "initiator" is used to 1902 refer to a node that starts the establishment of an LSP and the term 1903 "terminator" is used to refer to the node that is the target of the 1904 LSP. For a bi-directional LSPs, there is only one initiator and one 1905 terminator. 1907 Normally to establish a bi-directional LSP when using [RSVP-TE] or 1908 [CR-LDP] two unidirectional paths must be independently established. 1909 This approach has the following disadvantages: 1911 1. The latency to establish the bi-directional LSP is equal to one 1912 round trip signaling time plus one initiator-terminator signaling 1913 transit delay. This not only extends the setup latency for 1914 successful LSP establishment, but it extends the worst-case latency 1915 for discovering an unsuccessful LSP to as much as two times the 1916 initiator-terminator transit delay. These delays are particularly 1917 significant for LSPs that are established for restoration purposes. 1919 2. The control overhead is twice that of a unidirectional LSP. This 1920 is because separate control messages (e.g. Path and Resv) must be 1921 generated for both segments of the bi-directional LSP. 1923 3. Because the resources are established in separate segments, route 1924 selection is complicated. There is also additional potential race 1925 for conditions in assignment of resources, which decreases the 1926 overall probability of successfully establishing the bi-directional 1927 connection. 1929 4. It is more difficult to provide a clean interface for SDH/SONET 1930 equipment that may rely on bi-directional hop-by-hop paths for 1931 protection switching. Note that existing SDH/SONET gear transmits 1932 the control information in-band with the data. 1934 5. Bi-directional optical LSPs (or lightpaths) are seen as a 1935 requirement for many optical networking service providers. 1937 With bi-directional LSPs both the downstream and upstream data 1938 paths, i.e. from initiator to terminator and terminator to 1939 initiator, are established using a single set of signaling messages. 1940 This reduces the setup latency to essentially one initiator- 1941 terminator round trip time plus processing time, and limits the 1943 E. Mannie et. al. Internet-Draft February 2003 35 1944 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 1946 control overhead to the same number of messages as a unidirectional 1947 LSP. 1949 For bi-directional LSPs, two labels must be allocated. Bi- 1950 directional LSP setup is indicated by the presence of an Upstream 1951 Label in the appropriate signaling message. 1953 9.11. Bi-directional LSP Contention Resolution 1955 Contention for labels may occur between two bi-directional LSP setup 1956 requests traveling in opposite directions. This contention occurs 1957 when both sides allocate the same resources (ports) at effectively 1958 the same time. The GMPLS signaling defines a procedure to resolve 1959 that contention, basically the node with the higher node ID will win 1960 the contention. To reduce the probability of contention, some 1961 mechanisms are also suggested. 1963 9.12. Rapid Notification of Failure 1965 GMPLS defines several signaling extensions that enable expedited 1966 notification of failures and other events to nodes responsible for 1967 restoring failed LSPs, and error handling. 1969 1. Acceptable Label Set for notification on Label Error: 1971 There are cases in traditional MPLS and in GMPLS that result in an 1972 error message containing an "Unacceptable label value" indication. 1973 When these cases occur, it can useful for the node generating the 1974 error message to indicate which labels would be acceptable. To cover 1975 this case, GMPLS introduces the ability to convey such information 1976 via the "Acceptable Label Set". An Acceptable Label Set is carried 1977 in appropriate protocol specific error messages. The format of an 1978 Acceptable Label Set is identical to a Label Set. 1980 2. Expedited notification: 1982 Extensions to RSVP-TE enable expedited notification of failures and 1983 other events to determined nodes. For CR-LDP there is not currently 1984 a similar mechanism. The first extension identifies where event 1985 notifications are to be sent. The second provides for general 1986 expedited event notification with a Notify message. Such extensions 1987 can be used by fast restoration mechanisms. Notifications may be 1988 requested in both the upstream and downstream directions. 1990 The Notify message differs from the currently defined error messages 1991 in that it can be "targeted" to a node other than the immediate 1992 upstream or downstream neighbor and that it is a generalized 1993 notification mechanism. The Notify message does not replace existing 1994 error messages. The Notify message may be sent either (a) normally, 1995 where non-target nodes just forward the Notify message to the target 1996 node, similar to ResvConf processing in [RSVP]; or (b) encapsulated 1997 in a new IP header whose destination is equal to the target IP 1998 address. 2000 E. Mannie et. al. Internet-Draft February 2003 36 2001 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2003 3. Faster removal of intermediate states: 2005 A specific RSVP optimization allowing in some cases the faster 2006 removal of intermediate states. This extension is used to deal with 2007 specific RSVP mechanisms. 2009 9.13. Link Protection 2011 Protection information is carried in the new optional Protection 2012 Information Object/TLV. It currently indicates the desired link 2013 protection for each link of an LSP. If a particular protection type, 2014 i.e., 1+1, or 1:N, is requested, then a connection request is 2015 processed only if the desired protection type can be honored. Note 2016 that GMPLS advertises the protection capabilities of a link in the 2017 routing protocols. Path computation algorithms may take this 2018 information into account when computing paths for setting up LSPs. 2020 Protection information also indicates if the LSP is a primary or 2021 secondary LSP. A secondary LSP is a backup to a primary LSP. The 2022 resources of a secondary LSP are normally not used until the primary 2023 LSP fails, but they may be used by other LSPs until the primary LSP 2024 fails over the secondary LSP. At that point, any LSP that is using 2025 the resources for the secondary LSP must be preempted. 2027 Six link protection types are currently defined as individual flags 2028 and can be combined: enhanced, dedicated 1+1, dedicated 1:1, shared, 2029 unprotected, extra traffic. See [GMPLS-SIG] section 7.1 for a 2030 precise definition of each. 2032 9.14. Explicit Routing and Explicit Label Control 2034 By using an explicit route the path taken by an LSP can be 2035 controlled more or less precisely. Typically, the node at the head- 2036 end of an LSP finds an explicit route and builds an Explicit Route 2037 Object (ERO)/ Explicit Route (ER) TLV that contains that route. 2038 Possibly, the edge node does not build any explicit route, and just 2039 transmit a signaling request to a default neighbor LSR (as IP/MPLS 2040 hosts would). For instance, an explicit route could be added to a 2041 signaling message by the first switching node, on behalf of the edge 2042 node. Note also that an explicit route is altered by intermediate 2043 LSRs during its progression towards the destination. 2045 The explicit route is originally defined by MPLS-TE as a list of 2046 abstract nodes (i.e. groups of nodes) along the explicit route. Each 2047 abstract node can be an IPv4 address prefix, an IPv6 address prefix, 2048 or an AS number. This capability allows the generator of the 2049 explicit route to have incomplete information about the details of 2050 the path. In the simplest case, an abstract node can be a full IP 2051 address (32 bits) that identifies a specific node (called a simple 2052 abstract node). 2054 MPLS-TE allows strict and loose abstract nodes. The path between a 2055 strict node and its preceding node must include only network nodes 2056 from the strict node and its preceding abstract node. The path 2058 E. Mannie et. al. Internet-Draft February 2003 37 2059 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2061 between a loose node and its preceding abstract node may include 2062 other network nodes that are not part of the loose node or its 2063 preceding abstract node. 2065 This explicit route was extended to include interface numbers as 2066 abstract nodes to support unnumbered interfaces; and further 2067 extended by GMPLS to include labels as abstract nodes. Having labels 2068 in an explicit route is an important feature that allows controlling 2069 the placement of an LSP with a very fine granularity. This is more 2070 likely to be used for TDM, LSC and FSC links. 2072 In particular, the explicit label control in the explicit route 2073 allows terminating an LSP on a particular outgoing port of an egress 2074 node. Indeed, a label sub-object/TLV must follow a sub-object/TLV 2075 containing the IP address, or the interface identifier (in case of 2076 unnumbered interface), associated with the link on which it is to be 2077 used. 2079 This can also be used when it is desirable to "splice" two LSPs 2080 together, i.e. where the tail of the first LSP would be "spliced" 2081 into the head of the second LSP. 2083 Another use is when an optimization algorithm is used for an 2084 SDH/SONET network. This algorithm can provide very detailed explicit 2085 routes, including the label (time-slot) to use on a link, in order 2086 to minimize the fragmentation of the SDH/SONET multiplex on the 2087 corresponding interface. 2089 9.15. Route recording 2091 In order to improve the reliability and the manageability of the LSP 2092 being established, the concept of the route recording was introduced 2093 in RSVP-TE to function as: 2095 - First, a loop detection mechanism to discover L3 routing loops, or 2096 loops inherent in the explicit route (this mechanism is strictly 2097 exclusive with the use of explicit routing objects). 2099 - Second, a route recording mechanism collects up-to-date detailed 2100 path information on a hop-by-hop basis during the LSP setup process. 2101 This mechanism provides valuable information to the source and 2102 destination nodes. Any intermediate routing change at setup time, in 2103 case of loose explicit routing, will be reported. 2105 - Third, a recorded route can be used as input for an explicit 2106 route. This is useful if a source node receives the recorded route 2107 from a destination node and applies it as an explicit route in order 2108 to "pin down the path". 2110 Within the GMPLS architecture only the second and third functions 2111 are mainly applicable for TDM, LSC and FSC layers. 2113 9.16. LSP modification and LSP re-routing 2115 E. Mannie et. al. Internet-Draft February 2003 38 2116 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2118 LSP modification and re-routing are two features already available 2119 in MPLS-TE. GMPLS does not add anything new. Elegant re-routing is 2120 possible with the concept of "make-before-break" whereby an old path 2121 is still used while a new path is set up by avoiding double 2122 reservation of resources. Then, the node performing the re-routing 2123 can swap on the new path and close the old path. This feature is 2124 supported with RSVP-TE (using shared explicit filters) and CR-LDP 2125 (using the action indicator flag). 2127 LSP modification consists in changing some LSP parameters, but 2128 normally without changing the route. It is supported using the same 2129 mechanism as re-routing. However, the semantic of LSP modification 2130 will differ from one technology to the other. For instance, further 2131 studies are required to understand the impact of dynamically 2132 changing some SDH/SONET circuit characteristics such as the 2133 bandwidth, the protection type, the transparency, the concatenation, 2134 etc. 2136 9.17. LSP administrative status handling 2138 GMPLS provides the optional capability to indicate the 2139 administrative status of an LSP by using a new Admin Status 2140 object/TLV. Administrative Status Information is currently used in 2141 two ways. 2143 In the first usage, Admin Status the object/TLV is carried in a 2144 Path/Label Request or Resv/Label Mapping message to indicate the 2145 administrative state of an LSP. In this usage, Administrative Status 2146 Information indicates the state of the LSP, which include "up" or 2147 "down", if it in a "testing" mode, and if deletion is in progress. 2149 Based on that administrative status, a node can take local 2150 decisions, like to inhibit alarm reporting when an LSP is in "down" 2151 or "testing" states, or to report alarms associated with the 2152 connection at a priority equal to or less than "Non service 2153 affecting". 2155 It is possible that some nodes along an LSP will not support the 2156 Admin Status Object/TLV. In the case of a non-supporting transit 2157 node, the object will pass through the node unmodified and normal 2158 processing can continue. 2160 In some circumstances, particularly optical networks, it is useful 2161 to set the administrative status of an LSP to "being deleted" before 2162 tearing it down in order to avoid non-useful generation of alarms. 2163 The ingress LSR precedes an LSP deletion by inserting an appropriate 2164 Admin Status Object/TLV in a Path/Label Request (with the 2165 modification action indicator flag set to modify) message. Transit 2166 LSRs process the Admin Status Object/TLV and forward it. The egress 2167 LSR answers in a Resv/Label Mapping (with the modification action 2168 indicator flag set to modify) message with the Admin Status object. 2169 Upon receiving this message and object, the ingress node sends a 2170 PathTear/Release message downstream to remove the LSP and normal 2171 RSVP/CR-LDP processing takes place. 2173 E. Mannie et. al. Internet-Draft February 2003 39 2174 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2176 In the second usage, the Admin Status object/TLV is carried in a 2177 Notification/Label Mapping (with the modification action indicator 2178 flag set to modify) message to request that the ingress node change 2179 the administrative state of an LSP. This allows intermediate and 2180 egress nodes to trigger the setting of administrative status. In 2181 particular this allows, intermediate or egress LSRs to request a 2182 release of an LSP initiated by the ingress node. 2184 9.18. Control channel separation 2186 In GMPLS, a control channel can be separated from the data channel. 2187 Indeed, the control channel can be implemented completely out-of- 2188 band for various reasons, e.g. when the data channel cannot carry 2189 in-band control information. This issue was even originally 2190 introduced to MPLS in connection with link bundling. 2192 In traditional MPLS there is an implicit one-to-one association of a 2193 control channel to a data channel. When such an association is 2194 present, no additional or special information is required to 2195 associate a particular LSP setup transaction with a particular data 2196 channel. 2198 Otherwise it is necessary to convey additional information in 2199 signaling to identify the particular data channel being controlled. 2200 GMPLS supports explicit data channel identification by providing 2201 interface identification information. GMPLS allows the use of a 2202 number of interface identification schemes including IPv4 or IPv6 2203 addresses, interface indexes (for unnumbered interfaces) and 2204 component interfaces (for bundled interfaces), unnumbered bunled 2205 interfaces are also supported. 2207 The choice of the data interface to use is always made by the sender 2208 of the Path/Label Request message, and indicated by including the 2209 data channel's interface identifier in the message using a new 2210 RSVP_HOP object sub-type/Interface TLV. 2212 For bi-directional LSPs, the sender chooses the data interface in 2213 each direction. In all cases but bundling, the upstream interface is 2214 implied by the downstream interface. For bundling, the Path/Label 2215 Request sender explicitly identifies the component interface used in 2216 each direction. The new object/TLV is used in Resv/Label Mapping 2217 message to indicate the downstream node's usage of the indicated 2218 interface(s). 2220 The new object/TLV can contain a list of embedded TLVs, each 2221 embedded TLV can be an IPv4 address, and IPv6 address, an interface 2222 index, a downstream component interface ID or an upstream component 2223 interface ID. In the last three cases, the embedded TLV contains 2224 itself an IP address plus an Interface ID, the IP address being used 2225 to identify the interface ID (it can be the router ID for instance). 2227 E. Mannie et. al. Internet-Draft February 2003 40 2228 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2230 There are cases where it is useful to indicate a specific interface 2231 associated with an error. To support these cases the IF_ID 2232 ERROR_SPEC RSVP Objects are defined. 2234 10. Forwarding Adjacencies (FA) 2236 To improve scalability of MPLS TE (and thus GMPLS) it may be useful 2237 to aggregate multiple TE LSPs inside a bigger TE LSP. Intermediate 2238 nodes see the external LSP only, they don't have to maintain 2239 forwarding states for each internal LSP, less signaling messages 2240 need to be exchanged and the external LSP can be somehow protected 2241 instead (or in addition) to the internal LSPs. This can considerably 2242 increase the scalability of the signaling. 2244 The aggregation is accomplished by (a) an LSR creating a TE LSP, (b) 2245 the LSR forming a forwarding adjacency out of that LSP (advertising 2246 this LSP as a Traffic Engineering (TE) link into ISIS/OSPF), (c) 2247 allowing other LSRs to use forwarding adjacencies for their path 2248 computation, and (d) nesting of LSPs originated by other LSRs into 2249 that LSP (e.g. by using the label stack construct in the case of 2250 IP). 2252 An LSR may (under its local configuration control) announce an LSP 2253 as a TE link into ISIS/OSPF. When this link is advertised into the 2254 same instance of ISIS/OSPF as the one that determines the route 2255 taken by the LSP, we call such a link a "forwarding adjacency" (FA). 2256 We refer to the LSP as the "forwarding adjacency LSP", or just FA- 2257 LSP. Note that since the advertised entity is a link in ISIS/OSPF, 2258 both the endpoint LSRs of the FA-LSP must belong to the same ISIS 2259 level/OSPF area (intra-area improvement of scalability). 2261 In general, creation/termination of a FA and its FA-LSP could be 2262 driven either by mechanisms outside of MPLS (e.g., via configuration 2263 control on the LSR at the head-end of the adjacency), or by 2264 mechanisms within MPLS (e.g., as a result of the LSR at the head-end 2265 of the adjacency receiving LSP setup requests originated by some 2266 other LSRs). 2268 ISIS/OSPF floods the information about FAs just as it floods the 2269 information about any other links. As a result of this flooding, an 2270 LSR has in its TE link state database the information about not just 2271 conventional links, but FAs as well. 2273 An LSR, when performing path computation, uses not just conventional 2274 links, but FAs as well. Once a path is computed, the LSR uses RSVP- 2275 TE/CR-LDP for establishing label binding along the path. FAs need 2276 simple extensions to signaling and routing protocols. 2278 10.1. Routing and Forwarding Adjacencies 2280 Forwarding adjacencies may be represented as either unnumbered or 2281 numbered links. A FA can also be a bundle of LSPs between two nodes. 2283 E. Mannie et. al. Internet-Draft February 2003 41 2284 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2286 FAs are advertised as GMPLS TE links such as defined in [HIERARCHY]. 2287 GMPLS TE links are advertised in OSPF and ISIS such as defined in 2288 [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. These last two specifications 2289 enhance [OSPF-TE] and [ISIS-TE] that defines a base TE link. 2291 When a FA is created dynamically, its TE attributes are inherited 2292 from the FA-LSP that induced its creation. [HIERARCHY] specifies how 2293 each TE parameter of the FA is inherited from the FA-LSP. Note that 2294 the bandwidth of the FA must be at least as big as the FA-LSP that 2295 induced it, but may be bigger if only discrete bandwidths are 2296 available for the FA-LSP. In general, for dynamically provisioned 2297 forwarding adjacencies, a policy-based mechanism may be needed to 2298 associate attributes to forwarding adjacencies. 2300 A FA advertisement could contain the information about the path 2301 taken by the FA-LSP associated with that FA. Other LSRs may use this 2302 information for path computation. This information is carried in a 2303 new OSPF and IS-IS TLV called the Path TLV. 2305 It is possible that the underlying path information might change 2306 over time, via configuration updates, or dynamic route 2307 modifications, resulting in the change of that TLV. 2309 If forwarding adjacencies are bundled (via link bundling), and if 2310 the resulting bundled link carries a Path TLV, the underlying path 2311 followed by each of the FA-LSPs that form the component links must 2312 be the same. 2314 It is expected that forwarding adjacencies will not be used for 2315 establishing ISIS/OSPF peering relation between the routers at the 2316 ends of the adjacency. 2318 LSP hierarchy could exist both with the peer and with the overlay 2319 models. With the peer model the LSP hierarchy is realized via FAs 2320 and an LSP is both created and used as a TE link by exactly the same 2321 instance of the control plane. Creating LSP hierarchy with overlays 2322 doesn't involve the concept of FA. With the overlay model an LSP 2323 created (and maintained) by one instance of the GMPLS control plane 2324 is used as a TE link by another instance of the GMPLS control plane. 2325 Moreover, the nodes using a TE link are expected to have a routing 2326 and signaling adjacency. 2328 10.2. Signaling aspects 2330 For the purpose of processing the explicit route in a Path/Request 2331 message of an LSP that is to be tunneled over a forwarding 2332 adjacency, an LSR at the head-end of the FA-LSP views the LSR at the 2333 tail of that FA-LSP as adjacent (one IP hop away). 2335 10.3. Cascading of Forwarding Adjacencies 2337 With an integrated model several layers are controlled using the 2338 same routing and signaling protocols. A network may then have links 2339 with different multiplexing/demultiplexing capabilities. For 2341 E. Mannie et. al. Internet-Draft February 2003 42 2342 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2344 example, a node may be able to multiplex/demultiplex individual 2345 packets on a given link, and may be able to multiplex/demultiplex 2346 channels within a SONET payload on other links. 2348 A new OSPF and IS-IS sub-TLV has been defined to advertise the 2349 multiplexing capability of each interface: PSC, L2SC, TDM, LSC or 2350 FSC. This sub-TLV is named the Link Multiplex Capability sub-TLV and 2351 complements the sub-TLVs defined in [OSPF-TE-GMPLS] and [ISIS-TE- 2352 GMPLS]. The information carried in this sub-TLV is used to construct 2353 LSP regions, and determine region�s boundaries. 2355 Path computation may take into account region boundaries when 2356 computing a path for an LSP. For example, path computation may 2357 restrict the path taken by an LSP to only the links whose 2358 multiplexing/demultiplexing capability is PSC. When an LSP need to 2359 cross a region boundary, it can trigger the establishment of an FA 2360 at the underlying layer (i.e. the L2SC layer). This can trigger a 2361 cascading of FAs between layers with the following obvious order: 2362 L2SC, then TDM, then LSC, and then finally FSC. 2364 11. Routing and Signaling Adjacencies 2366 By definition, two nodes have a routing (ISIS/OSPF) adjacency if 2367 they are neighbors in the ISIS/OSPF sense. 2369 By definition, two nodes have a signaling (RSVP-TE/CR-LDP) adjacency 2370 if they are neighbors in the RSVP-TE/CR-LDP sense. Nodes A and B are 2371 RSVP-TE neighbors if they directly exchange RSVP-TE messages 2372 (Path/Resv) (e.g., as described in sections 7.1.1 and 7.1.2 of 2373 [HIERARCHY]). The neighbor relationship includes exchanging RSVP-TE 2374 Hellos. 2376 By definition, a Forwarding Adjacency (FA) is a TE Link between two 2377 GMPLS nodes whose path transits one or more other (G)MPLS nodes in 2378 the same instance of the (G)MPLS control plane. If two nodes have 2379 one or more non-FA TE Links between them, these two nodes are 2380 expected (although not required) to have a routing adjacency. If two 2381 nodes do not have any non-FA TE Links between them, it is expected 2382 (although not required) that these two nodes would not have a 2383 routing adjacency. To state the obvious, if the TE links between two 2384 nodes are to be used for establishing LSPs, the two nodes must have 2385 a signaling adjacency. 2387 If one wants to establish routing and/or signaling adjacency between 2388 two nodes, there must be an IP path between them. This IP path can 2389 be, for example, a TE Link with an interface switching capability of 2390 PSC, anything that looks likes an IP link (e.g., GRE tunnel, or a 2391 (bi-directional) LSP that with an interface switching capability of 2392 PSC). 2394 A TE link may not be capable of being used directly for maintaining 2395 routing and/or signaling adjacencies. This is because GMPLS routing 2396 and signaling adjacencies requires exchanging data on a per (IP/ISO) 2397 packet basis, and a TE link (e.g. a link between OXCs) may not be 2399 E. Mannie et. al. Internet-Draft February 2003 43 2400 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2402 capable of exchanging data on a per packet basis. In this case the 2403 routing and signaling adjacencies are maintained via a set of one or 2404 more control channels (see [LMP]). 2406 Two nodes may have a TE link between them even if they don't have a 2407 routing adjacency. Naturally, each node must run OSPF/ISIS with 2408 GMPLS extensions in order for that TE link to be advertised. More 2409 precisely, the node needs to run GMPLS extensions for TE Links with 2410 an interface switching capability (see [GMPLS-ROUTING]) other than 2411 PSC, and it needs to run either GMPLS or MPLS extensions for TE 2412 links with an interface switching capability of PSC. 2414 The mechanisms for Control Channel Separation [GMPLS-SIG] should be 2415 used (even if the IP path between two nodes is a TE link). I.e., 2416 RSVP-TE/CR-LDP signaling should use the Interface_ID (IF_ID) object 2417 to specify a particular TE link when establishing an LSP. 2419 The IP path could consist of multiple IP hops. In this case, the 2420 mechanisms of sections 7.1.1 and 7.1.2 of [HIERARCHY] should be used 2421 (in addition to Control Channel Separation). 2423 12. Control Plane Fault Handling 2425 There are two major types of faults that can impact a control plane. 2426 The first, referred to as control channel fault, relates to the case 2427 where control communication is lost between two neighboring nodes. 2428 If the control channel is embedded with the data channel, data 2429 channel recovery procedure should solve the problem. If the control 2430 channel is independent of the data channel additional procedures are 2431 required to recover from that problem. 2433 The second, referred to as nodal faults, relates to the case where a 2434 node losses its control state (e.g., after a restart) but does not 2435 loose its data forwarding state. 2437 In transport networks, such types of control plane faults should not 2438 have service impact on the existing connections. Under such 2439 circumstances, a mechanism must exist to detect a control 2440 communication failure and a recovery procedure must guarantee 2441 connection integrity at both ends of the control channel. 2443 For a control channel fault, once communication is restored routing 2444 protocols are naturally able to recover but the underlying signaling 2445 protocols must indicate that the nodes have maintained their state 2446 through the failure. The signaling protocol must also ensure that 2447 any state changes that were instantiated during the failure are 2448 synchronized between the nodes. 2450 For a nodal fault, a node's control plane restarts and losses most 2451 of it's state information. In this case, both upstream and 2452 downstream nodes must synchronize their state information with the 2453 restarted node. In order for any resynchronization to occur the node 2454 undergoing the restart will need to preserve some information, such 2455 as it's mappings of incoming to outgoing labels. 2457 E. Mannie et. al. Internet-Draft February 2003 44 2458 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2460 These issues are addressed in protocol specific fashions, see [RSVP- 2461 TE-GMPLS] and [CR-LDP-GMPLS]. Note that these cases only apply when 2462 there are mechanisms to detect data channel failures independent of 2463 control channel failures. 2465 The LDP Fault tolerant draft [LDP-FT] specifies the procedures to 2466 recover from a control channel failure. [RSVP-TE-GMPLS] specifies 2467 how to recover from both a control channel failure and a node 2468 failure. 2470 13. LSP Protection and Restoration 2472 This section discusses Protection and Restoration (P&R) issues for 2473 GMPLS LSPs. It is driven by the requirements outlined in [TEWG- 2474 RESTORE] and some of the principles outlined in [MPLS-RECOVERY]. It 2475 will be enhanced, as more GMPLS P&R mechanisms are defined. The 2476 scope of this section is clarified hereafter: 2478 - This section is only applicable when a fault impacting LSP(s) 2479 happens in the data/transport plane. Section 11 deals with control 2480 plane fault handling for nodal and control channel faults. 2482 - This section focuses on P&R at the TDM, LSC and FSC layers. There 2483 are specific P&R requirements at these layers not present at the 2484 PSC layer. 2486 - This section focuses on intra-area P&R as opposed to inter-area 2487 P&R and even inter-domain P&R. Note that the P&R can even be more 2488 restricted, e.g. to a collection of like customer equipment, or a 2489 collection of equipment of like capabilities, in one single 2490 routing area. 2492 - This section focuses on intra-layer P&R (horizontal hierarchy as 2493 defined in [TEWG-RESTORE]) as opposed to the inter-layer P&R 2494 (vertical hierarchy). 2496 - P&R mechanisms are in general designed to handle single failures, 2497 which makes SRLG diversity a necessity. Recovery from multiple 2498 failures requires further study. 2500 - Both mesh and ring like topologies are supported. 2502 In the following, we assume that: 2504 - TDM, LSC and FSC devices are more generally committing recovery 2505 resources in a non best effort way. Recovery resources are either 2506 allocated and used, or at least logically reserved (used or not by 2507 preemptable extra traffic but unavailable anyway for regular 2508 working traffic). 2510 - Shared P&R mechanisms are valuable to operators in order to 2511 maximize their network utilization. 2513 E. Mannie et. al. Internet-Draft February 2003 45 2514 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2516 - Sending preemptable excess traffic on recovery resources is a 2517 valuable feature for operators. 2519 13.1. Protection escalation across domains and layers 2521 To describe the P&R architecture, one must consider two dimensions 2522 of hierarchy [TE-RESTORE]: 2524 - A horizontal hierarchy consisting of multiple P&R domains, which 2525 is important in an LSP based protection scheme. The scope of P&R 2526 may extend over a link (or span), an administrative domain or sub- 2527 network, an entire LSP. 2529 An administrative domain may consist of a single P&R domain or as 2530 a concatenation of several smaller P&R domains. The operator can 2531 configure P&R domains, based on customers' requirements, and on 2532 network topology and traffic engineering constraints. 2534 - A vertical hierarchy consisting of multiple layers of P&R with 2535 varying granularities (packet flows, STS trails, lightpaths, 2536 fibers, etc). 2538 In the absence of adequate P&R coordination, a fault may propagate 2539 from one level to the next within a P&R hierarchy. It can lead to 2540 "collisions" and simultaneous recovery actions may lead to race 2541 conditions, reduced resource utilization, or instabilities 2542 [MANCHESTER]. Thus, a consistent escalation strategy is needed to 2543 coordinate recovery across domains and layers. The fact that GMPLS 2544 can be used at different layers could simplify this coordination. 2546 There are two types of escalation strategies: bottom-up and top- 2547 down. The bottom-up approach assumes that "lower-level" recovery 2548 schemes are more expedient, and therefore we can inhibit or hold 2549 off higher-level P&R. The Top-down approach attempts service P&R 2550 at the higher levels before invoking "lower level" P&R. Higher- 2551 layer P&R is service selective, and permits "per-CoS" or "per-LSP" 2552 re-routing. 2554 SLA's between network operators and their clients are needed to 2555 determine the necessary timescales for P&R at each layer and at each 2556 domain. 2558 13.2. Mapping of Services to P&R Resources 2560 The choice of a P&R scheme is a tradeoff between network utilization 2561 (cost) and service interruption time. In light of this tradeoff, 2562 network service providers are expected to support a range of 2563 different service offerings or service levels. 2565 One can classify LSPs into one of a small set of service levels. 2566 Among other things, these service levels define the reliability 2567 characteristics of the LSP. The service level associated with a 2568 given LSP is mapped to one or more P&R schemes during LSP 2569 establishment. An advantage that mapping is that an LSP may use 2571 E. Mannie et. al. Internet-Draft February 2003 46 2572 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2574 different P&E schemes in different segments of a network (e.g. some 2575 links may be span protected, whilst other segments of the LSP may 2576 utilize ring protection). These details are likely to be service 2577 provider specific. 2579 An alternative to using service levels is for an application to 2580 specify the set of specific P&R mechanisms to be used when 2581 establishing the LSP. This allows greater flexibility in using 2582 different mechanisms to meet the application requirements. 2584 A differentiator between these service levels is service 2585 interruption time in the event of network failures, which is defined 2586 as the length of time between when a failure occurs and when 2587 connectivity is re-established. The choice of service level (or P&R 2588 scheme) should be dictated by the service requirements of different 2589 applications. 2591 13.3. Classification of P&R mechanism characteristics 2593 The following figure provides a classification of the possible 2594 provisioning types of recovery LSPs, and of the levels of 2595 overbooking that is possible for them. 2597 + Computed on +Established +--Resources pre 2598 | demand | on demand | allocated 2599 Recovery LSP | | | 2600 Provisioning -+ Pre computed +Pre established +--Resources 2601 allocated on 2602 demand 2603 +--Dedicated - 1:1, 1 2604 | 2605 | 2606 +-- Shared - 1:N, Ring, Shared mesh 2607 Level of | 2608 Overbooking ---+-- Best effort 2610 13.4. Different Stages in P&R 2612 Recovery from a network fault or impairment takes place in several 2613 stages as discussed in [MPLS-RECOVERY], including fault detection, 2614 fault localization, notification, recovery (i.e. the P&R itself) and 2615 restoral (i.e. returning the traffic to the original working LSP or 2616 to a new one) of traffic. 2618 - Fault detection is technology and implementation dependent. In 2619 general, failures are detected by lower layer mechanisms (e.g. 2620 SONET/SDH, Loss-of-Light (LOL)). When a node detects a failure, an 2621 alarm may be passed up to a GMPLS entity, which will take 2622 appropriate actions, or the alarm may be propagated at the lower 2623 layer (e.g. SONET/SDH AIS). 2625 - Fault localization can be done with the help of GMPLS, e.g. using 2626 LMP for fault localization (see section 8.4). 2628 E. Mannie et. al. Internet-Draft February 2003 47 2629 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2631 - Fault notification can also be achieved through GMPLS, e.g. using 2632 GMPLS RSVP-TE/CR-LDP notification (see section 9.12). 2634 - This section focuses on the different mechanisms available for 2635 recovery and restoral of traffic once fault detection, 2636 localization and notification have taken place. 2638 13.5. Recovery Strategies 2640 Network P&R techniques can be divided into Protection and 2641 Restoration. In protection, resources between the protection 2642 endpoints are established before failure, and connectivity after 2643 failure is achieved simply by switching performed at the protection 2644 end-points. In contrast, restoration uses signaling after failure to 2645 allocate resources along the recovery path. 2647 - Protection aims at extremely fast reaction times and may rely on 2648 the use of overhead control fields for achieving end-point 2649 coordination. Protection for SONET/SDH networks is described in 2650 [G.841] and [ANSI-T1.105]. Protection mechanisms can be further 2651 classified by the level of redundancy and sharing. 2653 - Restoration mechanisms rely on signaling protocols to coordinate 2654 switching actions during recovery, and may involve simple re- 2655 provisioning, i.e. signaling only at the time of recovery; or pre- 2656 signaling, i.e., signaling prior to recovery. 2658 In addition, P&R can be applied on a local or end-to-end basis. In 2659 the local approach, P&R is focused on the local proximity of the 2660 fault in order to reduce delay in restoring service. In the end-to- 2661 end approach, the LSP originating and terminating nodes control 2662 recovery. 2664 Using these strategies, the following recovery mechanisms can be 2665 defined. 2667 Editor's note: for each mechanism hereafter, it is intended to add 2668 references to the appropriate GMPLS and/or technology specific 2669 mechanisms. 2671 13.6. Recovery mechanisms: Protection schemes 2673 Note that protection schemes are usually defined in technology 2674 specific ways, but this does not preclude other solutions. 2676 - 1+1 Link Protection: Two pre-provisioned resources are used in 2677 parallel. For example, data is transmitted simultaneously on two 2678 parallel links and a selector is used at the receiving node to 2679 choose the best source. [Mechanisms reference to be added]. 2681 - 1:N Link Protection: Working and protecting resources (N working, 2682 1 backup) are pre-provisioned. If a working resource fails, the 2683 data is switched to the protecting resource, using a coordination 2684 mechanism (e.g. in overhead bytes). More generally, N working and 2686 E. Mannie et. al. Internet-Draft February 2003 48 2687 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2689 M protecting resources can be assigned for M:N link protection. 2690 [Mechanisms reference to be added]. 2692 - Enhanced Protection: Various mechanisms such as protection rings 2693 can be used to enhance the level of protection beyond single link 2694 failures to include the ability to switch around a node failure or 2695 multiple link failures within a span, based on a pre-established 2696 topology of protection resources. [Mechanisms reference to be 2697 added]. 2699 - 1+1 LSP Protection: Simultaneous data transmission on working and 2700 protecting LSPs and tail-end selection can be applied. [Mechanisms 2701 reference to be added]. 2703 13.7. Recovery mechanisms: Restoration schemes 2705 Restoration is possible thanks to the use of a distributed control 2706 plane like GMPLS in multiple of tenths of ms. It is much harder to 2707 achieve when only an NMS is used, and can only be done in that case 2708 in a multiple of seconds. 2710 - End-to-end LSP restoration with re-provisioning: An end-to-end 2711 restoration path is established after failure. The restoration 2712 path may be dynamically calculated after failure, or pre- 2713 calculated before failure (often during LSP establishment). 2714 Importantly, no signaling is used along the restoration path 2715 before failure, and no restoration bandwidth is reserved. As a 2716 result, there is no guarantee that a given restoration path is 2717 available when a failure occurs. Thus one may have to crankback to 2718 search for an available path. [Mechanisms reference to be added]. 2720 - End-to-end LSP restoration with pre-signaled recovery bandwidth 2721 reservation and no label pre-selection: An end-to-end restoration 2722 path is pre-calculated before failure and a signaling message is 2723 sent along this pre-selected path to reserve bandwidth, but labels 2724 are not selected. [Mechanisms reference to be added]. 2726 The resources reserved on each link of a restoration path may be 2727 shared across different working LSPs that are not expected to fail 2728 simultaneously. Local node policies can be applied to define the 2729 degree to which capacity is shared across independent failures. 2730 Upon failure detection, LSP signaling is initiated along the 2731 restoration path to select labels, and to initiate the appropriate 2732 cross-connections. [Mechanisms reference to be added]. 2734 - End-to-end LSP restoration with pre-signaled recovery bandwidth 2735 reservation and label pre-selection: An end-to-end restoration 2736 path is pre-calculated before failure and a signaling procedure is 2737 initiated along this pre-selected path on which bandwidth is 2738 reserved and labels are selected. Resources reserved on each link 2739 may be shared across different working LSPs that are not expected 2740 to fail simultaneously. In networks based on TDM, LSC and FSC 2741 technology, LSP signaling is used after failure detection to 2742 establish cross-connections at the intermediate switches on the 2744 E. Mannie et. al. Internet-Draft February 2003 49 2745 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2747 restoration path using the pre-selected labels. [Mechanisms 2748 reference to be added]. 2750 - Local LSP restoration: the above approaches can be applied on a 2751 local basis rather than end-to-end, in order to reduce recovery 2752 time. [Mechanisms reference to be added]. 2754 13.8. Schema selection criteria 2756 This section discusses criteria that could be used by the operator 2757 in order to make a choice among the various P&R mechanisms. 2759 - Robustness: In general, the less pre-planning of the restoration 2760 path, the more robust the restoration scheme is to a variety of 2761 failures, provided that adequate resources are available. 2762 Restoration schemes with pre-planned paths, will not be able to 2763 recover from network failures that simultaneously affect both the 2764 working and restoration paths. Thus, these paths should ideally be 2765 chosen to be as disjoint as possible (i.e. SRLG and node 2766 disjoint), so that any single failure event will not affect both 2767 paths. The risk of simultaneous failure of the two paths can be 2768 reduced by recalculating the restoration path whenever a failure 2769 occurs along it. 2771 The pre-selection of a label gives less flexiblity for multiple 2772 failure scenarios than no label pre-selection. If failures occur 2773 that affect two LSPs that are sharing a label at a common node 2774 along their restoration routes, then only one of these LSPs can be 2775 recovered, unless the label assignment is changed. 2777 The robustness of a restoration scheme is also determined by the 2778 amount of reserved restoration bandwidth - as the amount of 2779 restoration bandwidth sharing increases (reserved bandwidth 2780 decreases), the restoration scheme becomes less robust to 2781 failures. Restoration schemes with pre-signaled bandwidth 2782 reservation (with or without label pre-selection) can reserve 2783 adequate bandwidth to ensure recovery from any specific set of 2784 failure events, such as any single SRLG failure, any two SRLG 2785 failures etc. Clearly, more restoration capacity is allocated if a 2786 greater degree of failure recovery is required. Thus, the degree 2787 to which the network is protected is determined by the policy that 2788 defines the amount of reserved restoration bandwidth. 2790 - Recovery time: In general, the more pre-planning of the 2791 restoration route, the more rapid the P&R scheme. Protection 2792 schemes generally recover faster than restoration schemes. 2793 Restoration with pre-signaled bandwidth reservation are likely to 2794 be (significantly) faster than path restoration with re- 2795 provisioning, especially because of the elimination of any 2796 crankback. Local restoration will generally be faster than end-to- 2797 end schemes. 2799 Recovery time objectives for SONET/SDH protection switching (not 2800 including time to detect failure) are specified in [G.841] at 50 2802 E. Mannie et. al. Internet-Draft February 2003 50 2803 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2805 ms, taking into account constraints on distance, number of 2806 connections involved, and in the case of ring enhanced protection, 2807 number of nodes in the ring. 2809 Recovery time objectives for restoration mechanisms are being 2810 defined through a separate effort [TE-RESTORE]. 2812 - Resource Sharing: 1+1 and 1:N link and LSP protection require 2813 dedicated recovery paths with limited ability to share resources: 2814 1+1 allows no sharing, 1:N allows some sharing of protection 2815 resources and support of extra (preemptable) traffic. Flexibility 2816 is limited because of topology restrictions, e.g. fixed ring 2817 topology for traditional enhanced protection schemes. 2819 The degree to which restoration schemes allow sharing amongst 2820 multiple independent failures is directly dictated by the size of 2821 the restoration pool. In restoration schemes with re-provisioning, 2822 a pool of restoration capacity can be defined from which all 2823 restoration routes are selected after failure. Thus, the degree of 2824 sharing is defined by the amount of available restoration 2825 capacity. In restoration with pre-signaled bandwidth reservation, 2826 the amount of reserved restoration capacity is determined by the 2827 local bandwidth reservation policies. In all restoration schemes, 2828 pre-emptable resources can use spare restoration capacity when 2829 that capacity is not being used for failure recovery. 2831 14. Network Management 2833 Service Providers (SPs) use network management extensively to 2834 configure, monitor or provision various devices in their network. It 2835 is important to note that a SP�s equipment may be distributed across 2836 geographically separate sites, making distributed management even 2837 more important. The service provider should utilize an NMS system 2838 and standard management protocols such as SNMP [RFC1901] [RFC1902] 2839 [RFC1903] [RFC1904] [RFC1905] [RFC1906] and its associated MIBs as 2840 standard interfaces to configure, monitor and provision devices at 2841 various locations. The service provider may also wish to use the 2842 command line interface (CLI) provided by vendors with their devices, 2843 but this however, is not a standard or recommended solution due to 2844 the fact that there is no standard CLI language or interface, which 2845 results in N different CLI�s in a network with devices from N 2846 different vendors. In the context of GMPLS, it is extremely 2847 important for standard interfaces to the SP�s devices (SNMP) to 2848 exist due to the nature of the technology itself. Since GMPLS 2849 comprises many different layers of control-plane and data-plane 2850 technology, it is important for management interfaces in this area 2851 to be flexible enough to allow the manager to manage GMPLS easily, 2852 and in a standard way. 2854 14.1. Network Management Systems (NMS) 2856 The NMS system should maintain the collective information about each 2857 device within the system. Note that the NMS system may actually be 2858 comprised of several distributed applications (i.e.: alarm 2860 E. Mannie et. al. Internet-Draft February 2003 51 2861 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2863 aggregators, configuration consoles, polling applications, etc...) 2864 that collectively comprises the SP�s NMS. In this way, it can make 2865 provisioning and maintenance decisions with the full knowledge of 2866 the entire SP network. Configuration or provisioning information 2867 (i.e.: requests for new services) could be entered into the NMS and 2868 subsequently distributed via SNMP to the remote devices, making the 2869 SP�s job of managing the network much more compact and effortless 2870 than having to manage each device individually (i.e.: via CLI). 2871 Security and access control can be achieved through the use of 2872 SNMPv3 and the View Access Control Model [SNMPv3VACM]. This approach 2873 can be very effectively used within an SP network, since the SP has 2874 access to and control over all devices within its domain. 2875 Standardized MIBs will need to be developed before this approach can 2876 be used ubiquitously to provision, configure and monitor devices in 2877 non-heterogeneous networks or across SP boundaries. 2879 14.2. Management Information Base (MIB) 2881 In the context of GMPLS, it is extremely important for standard 2882 interfaces to devices to exist due to the nature of the technology 2883 itself. Since GMPLS comprises many different layers of control-plane 2884 technology, it is important for SNMP MIBs in this area to be 2885 flexible enough to allow the manager to manage the entire control 2886 plane. This should be through a set of MIBs that may cooperate 2887 (i.e.: coordinated row-creation on the agent), or through more 2888 generalized MIBs that aggregate some of the desired actions to be 2889 taken and push those details down to the devices. It is important to 2890 note that in certain circumstances, it may be necessary to duplicate 2891 some small subset of manageable objects in new MIBs for the 2892 convenience of management. Control of some parts of GMPLS may also 2893 be achieved though the use of existing MIB interfaces (i.e.: 2894 existing SONET MIB), or though separate ones, which are yet to be 2895 defined. MIBs may have been previously defined in the IETF or ITU. 2896 Existing MIBs may need to be extended to facilitate some of the new 2897 functionality desired by GMPLS. In these cases, the working group 2898 should work on new versions of these MIBs so that these extensions 2899 can be added. 2901 14.3. Tools 2903 As in traditional networks, standard tools such as traceroute 2904 [RFC1393] and ping [RFC1739] are needed for debugging and 2905 performance monitoring of GMPLS networks, and mainly for the control 2906 plane topology that will mimic the data plane topology. Furthermore, 2907 such tools provide network reachability information. The GMPLS 2908 control protocols will need to expose certain pieces of information 2909 in order for these tools to function properly and to provide 2910 information germane to GMPLS. These tools should be made available 2911 via the CLI. These tools should also be made available for remote 2912 invocation via the SNMP interface [RFC2925]. 2914 14.4. Fault Correlation Between Multiple Layers 2916 E. Mannie et. al. Internet-Draft February 2003 52 2917 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2919 Due to the nature of GMPLS and the fact that potential layers may be 2920 involved in the control and transmission of GMPLS data and control 2921 information, it is therefore required that a fault in one layer be 2922 passed to the adjacent higher and lower layers in an effort to 2923 notify them of the fault. However, due to nature of these many 2924 layers, it is possible and even probable, that hundreds or even 2925 thousands of notifications may need to transpire between layers. 2926 This is undesirable for several reasons. First, these notifications 2927 will overwhelm the device. Second, if the device(s) are programmed 2928 to emit SNMP Notifications [RFC1901] then the large number of 2929 notifications the device may attempt to emit may overwhelm the 2930 network with a storm of notifications. Furthermore, even if the 2931 device emits the notifications, the NMS that must process these 2932 notifications will either be overwhelmed, or will be processing 2933 redundant information. That is, if 1000 interfaces at layer B are 2934 stacked above a single interface below it at layer A, and the 2935 interface at A goes down, the interfaces at layer B should not emit 2936 notifications. Instead, the interface at layer A should emit a 2937 single notification. The NMS receiving this notification should be 2938 able to correlate the fact that this interface has many others 2939 stacked above it and take appropriate action, if necessary. 2941 Devices that support GMPLS should provide mechanisms for 2942 aggregating, summarizing, enabling and disabling of inter-layer 2943 notifications for the reasons described above. In the context of 2944 SNMP MIBs, all MIBs that are used by GMPLS must provide 2945 enable/disable objects for all notification objects. Furthermore, 2946 these MIBs must also provide notification summarization objects or 2947 functionality (as described above) as well. NMS systems and standard 2948 tools which process notifications or keep track of the many layers 2949 on any given devices must be capable of processing the vast amount 2950 of information which may potentially be emitted by network devices 2951 running GMPLS at any point in time. 2953 15. Security considerations 2955 GMPLS defines a new control plane architecture for multiple types of 2956 network elements. In general, since LSPs established using GMPLS are 2957 expected to carry high volumes of data and consume significant 2958 network resources, security mechanisms are required to safeguard the 2959 underlying network against attacks on the control plane and/or 2960 unauthorized usage of data transport resources. 2962 Security requirements depend on the level of trust between nodes 2963 that exchange GMPLS control messages as well as the exposure of the 2964 control channel to third parties. In general, a network node may 2965 apply more relaxed security requirements when exchanging GMPLS 2966 control messages with nodes under the same administrative domain 2967 than when talking to nodes in a different domain. In this respect, 2968 network to user (UNI) and network-to-network interfaces are expected 2969 to have higher security requirements than node-to-node interfaces. 2971 Security mechanisms can provide two main properties: authentication 2972 and confidentiality. Authentication can provide origin verification, 2974 E. Mannie et. al. Internet-Draft February 2003 53 2975 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 2977 message integrity and replay protection, while confidentiality 2978 ensures that a third party cannot decipher the contents of a 2979 message. In situations where GMPLS deployment requires primarily 2980 authentication, the respective authentication mechanisms of the 2981 GMPLS component protocols may be used ([RFC2747], [RFC3036], 2982 [RFC2385], [LMP]). Additionally, the IPSEC suite of protocols 2983 ([RFC2402], [RFC2406], [RFC2409]) may be used to provide 2984 authentication, confidentiality or both, for a GMPLS control 2985 channel; this option offers the benefit of combined protection of 2986 all GMPLS component protocols. 2988 Note however that GMPLS itself introduces no new security 2989 considerations to the current MPLS-TE signaling (RSVP-TE, CR-LDP), 2990 routing protocols (OSPF-TE, IS-IS-TE) or network management 2991 protocols (SNMP). 2993 16. Acknowledgements 2995 This draft is the work of numerous authors and consists of a 2996 composition of a number of previous drafts in this area. 2998 Many thanks to Ben Mack-Crane (Tellabs) for all the useful SDH/SONET 2999 discussions that we had together. Thanks also to Pedro Falcao, 3000 Alexandre Geyssens, Michael Moelants, Xavier Neerdaels, and Philippe 3001 Noel from Ebone for their SDH/SONET and optical technical advice and 3002 support. Finally, many thanks also to Krishna Mitra (Calient) and 3003 Curtis Villamizar (Avici). 3005 A list of the drafts from which material and ideas were incorporated 3006 follows: 3008 [GMPLS-SIG] draft-ietf-mpls-generalized-signaling-07.txt 3009 Generalized MPLS - Signaling Functional Description 3011 [RSVP-TE-GMPLS] draft-ietf-mpls-generalized-rsvp-te-06.txt 3012 Generalized MPLS Signaling - RSVP-TE Extensions 3014 [CR-LDP-GMPLS] draft-ietf-mpls-generalized-cr-ldp-05.txt 3015 Generalized MPLS Signaling - CR-LDP Extensions 3017 [SONETSDH-GMPLS] draft-ietf-ccamp-gmpls-sonet-sdh-03.txt 3018 GMPLS Extensions for SONET and SDH Control 3020 [SONETSDH-EXT-GMPLS] draft-ietf-ccamp-gmpls-sonet-sdh-extensions- 3021 01.txt. GMPLS Extensions to Control Non-Standard 3022 SONET and SDH Features 3024 [G709-GMPLS] draft-ietf-ccamp-gmpls-g709-01.txt 3025 GMPLS Signaling Extensions for G.709 Optical 3026 Transport Networks Control 3028 [LMP] draft-ietf-mpls-lmp-02.txt 3029 Link Management Protocol (LMP) 3031 E. Mannie et. al. Internet-Draft February 2003 54 3032 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 3034 [LMP-WDM] draft-ietf-ccamp-lmp-wdm-00.txt 3035 LMP for WDM Optical Line Systems (LMP-WDM) 3037 [HIERARCHY] draft-ietf-mpls-lsp-hierarchy-04.txt 3038 LSP Hierarchy with MPLS TE 3040 [RSVP-TE-UNNUM] draft-ietf-mpls-rsvp-unnum-04.txt 3041 Signalling Unnumbered Links in RSVP-TE 3043 [CR-LDP-UNNUM] draft-ietf-mpls-crldp-unnum-04.txt 3044 Signalling Unnumbered Links in CR-LDP 3046 [BUNDLE] draft-ietf-mpls-bundle-01.txt 3047 Link Bundling in MPLS Traffic Engineering 3049 [GMPLS-ROUTING] draft-ietf-ccamp-gmpls-routing-02.txt 3050 Routing Extensions in Support of Generalized MPLS 3052 [OSPF-TE-GMPLS] draft-ietf-ccamp-ospf-gmpls-extensions-04.txt 3053 OSPF Extensions in Support of Generalized MPLS 3055 [ISIS-TE-GMPLS] draft-ietf-isis-gmpls-extensions-08.txt 3056 IS-IS Extensions in Support of Generalized MPLS 3058 17. References 3060 [RFC1393] G. Malkin, "Traceroute Using an IP Option", IETF 3061 RFC 1393, January 1993. 3063 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. 3064 Waldbusser, "Introduction to Community-based 3065 SNMPv2", IETF RFC 1901, January 1996. 3067 [RFC1902] Case, J., McCloghrie, K., Rose, M., and S. 3068 Waldbusser, "Structure of Management Information for 3069 Version 2 of the Simple Network Management Protocol 3070 (SNMPv2)", IETF RFC 1902, January 1996. 3072 [RFC1903] Case, J., McCloghrie, K., Rose, M., and S. 3073 Waldbusser, "Textual Conventions for Version 2 of the 3074 Simple Network Management Protocol (SNMPv2)", 3075 IETF RFC 1903, January 1996. 3077 [RFC1904] Case, J., McCloghrie, K., Rose, M., and S. 3078 Waldbusser, "Conformance Statements for Version 2 of 3079 the Simple Network Management Protocol (SNMPv2)", 3080 IETF RFC 1904, January 1996. 3082 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. 3083 Waldbusser, "Protocol Operations for Version 2 of 3084 the Simple Network Management Protocol (SNMPv2)", 3085 IETF RFC 1905, January 1996. 3087 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. 3089 E. Mannie et. al. Internet-Draft February 2003 55 3090 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 3092 Waldbusser, "Transport Mappings for Version 2 of 3093 the Simple Network Management Protocol (SNMPv2)", 3094 IETF RFC 1906, January 1996. 3096 [SNMPv3VACM] Wijnen, B., Presuhn, R., and K. McCloghrie, "View- 3097 based Access Control Model (VACM) for the Simple 3098 Network Management Protocol (SNMP)", IETF RFC 2575, 3099 April 1999. 3101 [RFC1739] Kessler G. and Shepard S., "A Primer On Internet and 3102 TCP/IP Tools", IETF RFC 1739, December 1994. 3104 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3105 Requirement Levels", BCP 14, IETF RFC 2119, March 1997. 3107 [RFC2328] J. Moy, "OSPF Version 2", IETF RFC 2328, Standard 3108 Track, April 1998. 3110 [RFC2370] R. Coltun, "The OSPF Opaque LSA Option", IETF RFC 2370 3111 Standard Track, July 1998. 3113 [RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP 3114 MD5 Signature Option", IETF RFC 2385, August 1998. 3116 [RFC2402] S. Kent and R. Atkinson, "IP Authentication Header", 3117 IETF RFC 2402, November 1998. 3119 [RFC2406] S. Kent and R. Atkinson, "IP Encapsulating Security 3120 Payload (ESP)", IETF RFC 2406, November 1998. 3122 [RFC2409] D. Harkins and D. Carrel, "The Internet Key Exchange 3123 (IKE)", IETF RFC 2409, November 1998. 3125 [RFC2747] F. Baker et al., "RSVP Cryptographic Authentication", 3126 IETF RFC 2747, January 2000. 3128 [RFC2925] K. White, "Definitions of Managed Objects for Remote 3129 Ping, Traceroute, and Lookup Operations", IETF RFC 3130 2925, September 2000. 3132 [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol 3133 Label Switching Architecture", IETF RFC 3031, January 3134 2001. 3136 [RFC3032] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. 3137 Farinacci, T. Li, A. Conta, "MPLS Label Stack 3138 Encoding", IETF RFC 3032, January 2001. 3140 [RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette, 3141 B. Thomas, "LDP Specification", IETF RFC 3036, January 3142 2001. 3144 [OSPF-TE] D. Katz, D. Yeung, and K. Kompella, "Traffic 3145 Engineering Extensions to OSPF", draft-katz-yeung-ospf- 3147 E. Mannie et. al. Internet-Draft February 2003 56 3148 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 3150 traffic-06.txt. 3152 [MPLS-TEO] D. Awduche et al., "Multi-Protocol Lambda Switching: 3153 Combining MPLS Traffic Engineering Control With Optical 3154 Crossconnects", Internet Draft, Work in Progress, 3155 draft-awduche-mpls-te-optical-03.txt, April 2001. 3157 [G.841] ITU-T Recommendation G.841, "Types and Characteristics 3158 of SDH Network Protection Architectures", October 1998. 3160 [ANSI-T1.105] "Synchronous Optical Network (SONET): Basic 3161 Description Including Multiplex Structure, Rates, and 3162 Formats", ANSI T1.105, 2000. 3164 [TE-RESTORE] W. Lai, D. McDysan, J. Boyle, et al, "Network Hierarchy 3165 and Multi-layer Survivability", Internet Draft, Work in 3166 Progress, draft-ietf-tewg-restore-hierarchy-00.txt, 3167 October 2001. 3169 [MPLS-RECOVERY] V. Sharma and F. Hellstrand (Editors), "A Framework 3170 for MPLS Recovery", Internet Draft, Work in Progress, 3171 draft-ietf-mpls-recovery-frmwrk-06.txt, July 2002. 3173 [SDH/SONET-GMPLS-FRAMEWORK] G. Bernstein, E. Mannie, V. Sharma, 3174 "Framework for GMPLS-based Control of SDH/SONET 3175 Networks", Internet Draft, Work in Progress, 3176 draft-ietf-ccamp-sdhsonet-control-01.txt, May 2002. 3178 [OLI-REQ] A. Fredette (Editor), "Optical Link Interface 3179 Requirements", Internet Draft, Work in Progress, 3180 draft-ietf-ccamp-oli-reqts-00.txt, February 2002. 3182 [MANCHESTER] J. Manchester, P. Bonenfant, C. Newton, "The Evolution 3183 of Transport Network Survivability", IEEE 3184 Communications, August 1999. 3186 18. Author's Address 3188 Eric Mannie 3189 Ebone (GTS) 3190 Terhulpsesteenweg 6A 3191 1560 Hoeilaart 3192 Belgium 3193 Phone: +32 2 658-5652 3194 Email: eric.mannie@gts.com 3196 E. Mannie et. al. Internet-Draft February 2003 57 3197 draft-ietf-ccamp-gmpls-architecture-03.txt August 2002 3199 Full Copyright Statement 3201 "Copyright (C) The Internet Society (date). All Rights Reserved. 3202 This document and translations of it may be copied and furnished to 3203 others, and derivative works that comment on or otherwise explain it 3204 or assist in its implementation may be prepared, copied, published 3205 and distributed, in whole or in part, without restriction of any 3206 kind, provided that the above copyright notice and this paragraph 3207 are included on all such copies and derivative works. However, this 3208 document itself may not be modified in any way, such as by removing 3209 the copyright notice or references to the Internet Society or other 3210 Internet organizations, except as needed for the purpose of 3211 developing Internet standards in which case the procedures for 3212 copyrights defined in the Internet Standards process must be 3213 followed, or as required to translate it into languages other than 3214 English. 3216 The limited permissions granted above are perpetual and will not be 3217 revoked by the Internet Society or its successors or assigns. 3219 This document and the information contained herein is provided on an 3220 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3221 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3222 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3223 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3224 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 3226 E. Mannie et. al. Internet-Draft February 2003 58