idnits 2.17.1 draft-ietf-ccamp-gmpls-overlay-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 373 has weird spacing: '...for the purpo...' -- 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 (February 2003) is 7738 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2205' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'RFC2961' is defined on line 309, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-04 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group George Swallow 3 Internet Draft Cisco Systems, Inc 4 Expiration Date: August 2003 5 John Drake 6 Calient Networks, Inc 8 Hirokazu Ishimatsu 9 Japan Telecom 11 Yakov Rekhter 12 Juniper Networks, Inc 14 February 2003 16 GMPLS RSVP Support for the Overlay Model 18 draft-ietf-ccamp-gmpls-overlay-01.txt 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups may also distribute 26 working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 Generalized MPLS defines both routing and signaling protocols for the 44 creation of Label Switched Paths (LSPs) in various transport 45 technologies. These protocols can be used to support a number of 46 deployment scenarios. This memo addresses the application of GMPLS 47 to the overlay model. 49 Contents 51 1 Introduction ........................................... 3 52 2 Addressing ............................................. 4 53 3 ERO Processing ......................................... 5 54 3.1 Path Message without ERO ............................... 6 55 3.2 Path Message with ERO .................................. 6 56 3.3 Explicit Label Control ................................. 6 57 4 RRO Processing ......................................... 6 58 5 Notification ........................................... 7 59 6 Connection Deletion .................................... 7 60 7 Security Considerations ................................ 7 61 8 Acknowledgments ........................................ 8 62 9 References ............................................. 8 63 9.1 Normative References ................................... 8 64 9.2 Informative References ................................. 8 65 10 Authors' Addresses ..................................... 9 66 11 Full Copywrite Statement ............................... 9 68 1. Introduction 70 Generalized MPLS defines both routing and signaling protocols for the 71 creation of Label Switched Paths (LSPs) in various transport 72 technologies. These protocols can be used to support a number of 73 deployment scenarios. In a peer model, edge-nodes support both a 74 routing and a signaling protocol. The protocol interactions between 75 an edge-node and a core node are the same as between two core-nodes. 76 In the overlay model, the core-nodes act more as a closed system. 77 The edge nodes do not participate in the routing protocol instance 78 that runs among the core nodes; in particular, the edge nodes are 79 unaware of the topology of the core nodes. There may, however, be a 80 routing protocol interaction between a core node and an edge node for 81 the exchange of reachability information to other edge nodes. 83 Overlay Overlay 84 Network +----------------------------------+ Network 85 +----------+ | | +----------+ 86 | +----+ | | +-----+ +-----+ +-----+ | | +----+ | 87 | | | | | | | | | | | | | | | | 88 | --+ EN +-+-----+--+ CN +----+ CN +----+ CN +---+-----+-+ EN +-- | 89 | | | | +--+--| | | | | | | | | | | 90 | +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ | 91 | | | | | | | | | | 92 +----------+ | | | | | | +----------+ 93 | | | | | | 94 +----------+ | | | | | | +----------+ 95 | | | | +--+--+ | +--+--+ | | | 96 | +----+ | | | | | +-------+ | | | +----+ | 97 | | +-+--+ | | CN +---------------+ CN | | | | | | 98 | --+ EN +-+-----+--+ | | +---+-----+-+ EN +-- | 99 | | | | | +-----+ +-----+ | | | | | 100 | +----+ | | | | +----+ | 101 | | +----------------------------------+ | | 102 +----------+ Core Network +----------+ 103 Overlay Overlay 104 Network Network 106 Legend: EN - Edge Node 107 CN - Core Node 109 Figure 1: Overlay Reference Model 111 Figure 1 shows a reference network. The core network is represented 112 by the large box in the center. It contains five core-nodes marked 113 'CN'. The four boxes around the edge marked "Overlay Network" 114 represent four islands of a single network overlaid network. Only 115 the nodes of this network with TE links into the core network are 116 shown. These nodes are called edge-nodes; the terminology is in 117 respect to the core network, not the overlay network. Note that each 118 box marked "Overlay Network" could contain many other nodes. Such 119 nodes are not shown; they do not participate in the signalling 120 described in this document. Only he edge-nodes can signal to set up 121 links across the core to other edge-nodes. Once a link is 122 established, presumably the edge-node will inform the other nodes of 123 the overlay network of its existence. How this is accomplished is 124 beyond the scope of this document. However, one possible means is 125 using a forwarding adjacency as described in [MPLS-HIER]. 127 In the overlay model there may be restrictions on what may be 128 signaled between an edge-node and a core-node. This memo addresses 129 the application of GMPLS to the overlay model. Specifically it 130 addresses RSVP procedures between an edge-node and a core-node in the 131 overlay model. All RSVP procedures are assumed to be identical to 132 [RFC3473] except as noted in this document. 134 This document primarily addresses interactions between an edge-node 135 and it's adjacent (at the data plane) core-node. Except where noted, 136 the term core-node refers to the node which is immediately adjacent 137 to an edge-node across a particular data plane interface. The term 138 core-nodes, however, refers to all nodes in the core. 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 2. Addressing 146 Addresses for edge-nodes in the overlay model are drawn from the same 147 address space as the edge-nodes use to address their adjacent core- 148 nodes. This may be the same address space as used by the core-nodes 149 to communicate among themselves or it may be a VPN space supported by 150 the core-nodes as an overlay. 152 To be more specific, an edge-node and its attached core-node must 153 share the same address space which is used by GMPLS. A set of 154 tuples share the same address space if the 155 edge-nodes in the set could establish LSPs (through the core-nodes) 156 among themselves (note that edge-nodes in the set may be a subset of 157 all the edge-nodes). The address space used by the core-nodes to 158 communicate among themselves may, but need not be shared with the 159 address space used by any of the tuples. 161 An edge-node is identified by either a single IP address representing 162 its Node-ID, or by one or more numbered TE links that connect the 163 edge-node to the core-nodes. Core-nodes are assumed to be ignorant 164 of any other addresses associated with an edge-node (i.e. addresses 165 which are not used in signaling connections through the GMPLS core). 167 An edge-node need only know its own address, an address of the 168 adjacent core-node, and know (or be able to resolve) the address of 169 any other edge-node to which it wishes to connect. 171 A core-node need only know (and track) the addresses on interfaces 172 between that core-node and its attached edge-nodes, as well as the 173 Node IDs of those edge-nodes. In addition, a core-node needs to know 174 the interface addresses and Node IDs of other edge-nodes to which an 175 attached edge-node is permitted to connect. 177 When forming a SENDER_TEMPLATE the ingress edge-node includes either 178 its Node-ID or the address of one of its numbered TE links. In the 179 latter case the connection will only be made over this interface. 181 When forming a SESSION_OBJECT, the ingress edge-node includes either 182 the Node-ID of the egress edge-device or the address of one of the 183 egress' numbered TE links. In the latter case the connection will 184 only be made over this interface. The Extended_Tunnel_ID of the 185 SESSION Object is set to either zero or to an address of the ingress 186 edge-device. 188 Links may be either numbered or unnumbered. Further, links may be 189 bundled or unbundled. See [GMPLS-ARCH], [RFC3471], [BUNDLE], and 190 [RFC3477]. 192 3. ERO Processing 194 An edge-node MAY include an ERO. A core-node MAY reject a Path 195 message that contains an ERO. Such behavior is controlled by 196 (hopefully consistent) configuration. If a core-node rejects a Path 197 message due to the presence of an ERO it SHOULD return an PathErr 198 message with an error code of "Unknown object class" toward the 199 sender. This causes the path setup to fail. 201 Further a core-node MAY accept EROs which only include the ingress 202 edge-node, the ingress core-node, the egress core-node and the egress 203 edge-node. This is to support explicit label control on the edge- 204 node interface, see below. If a core-node rejects a Path message due 205 to the presence of an ERO not of the permitted format it SHOULD 206 return an PathErr message with an error code of Bad Explicit Route 207 Object as defined in [RFC3209]. 209 3.1. Path Message without ERO 211 When a core-node receives a Path message from an edge-node that 212 contains no ERO, it MUST calculate a route to the destination and 213 include that route in a ERO, before forwarding the PATH message. One 214 exception would be if the egress edge-node were also adjacent to this 215 core-node. If no route can be found, the core-node SHOULD return a 216 PathErr message with an error code and value of 24,5 - "No route 217 available toward destination". 219 3.2. Path Message with ERO 221 When a core-node receives a Path message from an edge-node that 222 contains an ERO, it SHOULD verify the route against its topology 223 database before forwarding the PATH message. If the route is not 224 viable, then a PathErr message with an error code and value of 24,5 - 225 "No route available toward destination" should be returned. 227 3.3. Explicit Label Control 229 In order to support explicit label control and full identification of 230 the egress link an ingress edge-node may include an ERO that consists 231 of only the last hop. This is signaled by setting the first 232 subobject of the ERO to the node-ID of the egress core-node with the 233 L-bit set. Following this subobject are all other subobjects 234 necessary to identify the link and labels as they would normally 235 appear. 237 4. RRO Processing 239 An edge-node MAY include an RRO. A core-node MAY remove the RRO from 240 the Path message before forwarding it. Further the core-node may 241 remove the RRO from a Resv message before forwarding it to the edge- 242 node. Such behavior is controlled by (hopefully consistent) 243 configuration. 245 Further a core-node MAY edit the RRO in a Resv message such that it 246 includes only the subobjects from the egress core-node through the 247 egress edge-node. This is to allow the ingress node to be aware of 248 the selected link and labels on at the far end of the connection. 250 5. Notification 252 An edge-node MAY include a NOTIFY_REQUEST object in both the Path and 253 Resv messages it generates. A core-node MAY remove the 254 NOTIFY_REQUEST object from the Path or Resv message before forwarding 255 it. Core-nodes may send Notification messages to edge-nodes which 256 have included the NOTIFY_REQUEST object. 258 Further if no NOTIFY_REQUEST object is present in the Path or Resv 259 message (either because it was not included or because it was 260 removed) then the core-node adjacent to the edge-node may include a 261 NOTIFY_REQUEST object to set its value to its own address. 263 6. Connection Deletion 265 RSVP currently deletes connections using either a single pass 266 PathTear message, or a ResvTear and PathTear message combination. 267 Upon receipt of the PathTear message, a node deletes the connection 268 state and forwards the message. In optical networks, however, it is 269 possible that the deletion of a connection (e.g., removal of the 270 cross-connect) in a node may cause the connection to be perceived as 271 failed in downstream nodes (e.g., loss of frame, loss of light, 272 etc.). This may in turn lead to management alarms and perhaps the 273 triggering of restoration/protection for the connection. 275 To address this issue, the graceful connection deletion procedure 276 SHOULD be followed. Under this procedure, an ADMIN_STATUS object MUST 277 be sent in Path or Resv message along the connection's path to inform 278 all nodes enroute of the intended deletion, prior to the actual 279 deletion of the connection. The procedure is described in [RFC3473]. 281 7. Security Considerations 283 This draft imposes no new security risks over [RFC3473]. In fact it 284 represents a lower trust model between the core and edge-nodes as the 285 core is permitted to hide its topology from the edge-nodes. The core 286 is also permitted to restrict the actions of edge-nodes by filtering 287 out specific RSVP objects. 289 8. Acknowledgments 291 The authors would like to thank Kireeti Kompella, Jonathan Lang, 292 Dimitri Papadimitriou, Dimitrios Pendarakis and Bala Rajagopalan for 293 their comments and input. 295 9. References 297 9.1. Normative References 299 [RFC3471] Berger, L., "Generalized MPLS Signaling Functional 300 Description", RFC 3471, January 2003. 302 [RFC3473] Berger, L., "Generalized MPLS Signaling RSVP-TE 303 Extensions", RFC 3473, January 2003. 305 [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol 306 -- Version 1 Functional Specification", RFC 2205, 307 September 1997. 309 [RFC2961] Berger, L. et al, "RSVP Refresh Overhead Reduction 310 Extensions", RFC 2961, April 2001 312 [RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for 313 LSP Tunnels", RFC 3209, December 2001. 315 9.2. Informative References 317 [GMPLS-ARCH] Mannie, E, et al., "Generalized Multi-Protocol 318 Label Switching (GMPLS) Architecture", Internet Draft, 319 draft-ietf-ccamp-gmpls-architecture-04.txt, Feb., 2003. 321 [MPLS-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with 322 MPLS TE", Internet Draft, 323 draft-ietf-mpls-lsp-hierarchy-08.txt, Sep., 2001. 325 [BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link 326 Bundling in MPLS Traffic Engineering", Internet Draft, 327 draft-ietf-mpls-bundle-04.txt, July, 2002. 329 [RFC3477] Kompella, K., and Rekhter, Y., "Signalling Unnumbered 330 Links in RSVP-TE", RFC 3477, January 2003. 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels," RFC 2119. 335 10. Authors' Addresses 337 John Drake 338 Calient Networks 339 5853 Rue Ferrari 340 San Jose, CA 95138 341 Phone: +1 408 972 3720 342 Email: jdrake@calient.net 344 Hirokazu Ishimatsu 345 Japan Telecom Co., Ltd. 346 2-9-1 Hatchobori, Chuo-ku, Tokyo, 104-0032, Japan 347 Tel: +81 3 5540 8493 348 Email: hirokazu.ishimatsu@japan-telecom.co.jp 350 Yakov Rekhter 351 Juniper Networks, Inc. 352 Email: yakov@juniper.net 354 George Swallow 355 Cisco Systems, Inc. 356 250 Apollo Drive 357 Chelmsford, MA 01824 358 Phone: +1 978 497 8143 359 Email: swallow@cisco.com 361 11. Full Copywrite Statement 363 Copyright (C) The Internet Society (2003). All Rights Reserved. 365 This document and translations of it may be copied and furnished to 366 others, and derivative works that comment on or otherwise explain it 367 or assist in its implementation may be prepared, copied, published 368 and distributed, in whole or in part, without restriction of any 369 kind, provided that the above copyright notice and this paragraph are 370 included on all such copies and derivative works. However, this 371 document itself may not be modified in any way, such as by removing 372 the copyright notice or references to the Internet Society or other 373 Internet organizations, except as needed for the purpose of 374 developing Internet standards in which case the procedures for 375 copyrights defined in the Internet Standards process must be 376 followed, or as required to translate it into languages other than 377 English. 379 The limited permissions granted above are perpetual and will not be 380 revoked by the Internet Society or its successors or assigns. 382 This document and the information contained herein is provided on an 383 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 384 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 385 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 386 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 387 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.