idnits 2.17.1 draft-ietf-ccamp-gmpls-overlay-00.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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (January 2003) is 7773 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RSVP-TE-UNUM' is mentioned on line 184, but not defined == Unused Reference: 'RFC2205' is defined on line 304, but no explicit reference was found in the text == Unused Reference: 'RFC2961' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'RSVP-UNNUM' is defined on line 328, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-08 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-07 == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-03 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-rsvp-unnum-07 Summary: 5 errors (**), 0 flaws (~~), 11 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: July 2003 5 John Drake 6 Calient Networks, Inc 8 Hirokazu Ishimatsu 9 Japan Telecom 11 Yakov Rekhter 12 Juniper Networks, Inc 14 January 2003 16 GMPLS RSVP Support for the Overlay Model 18 draft-ietf-ccamp-gmpls-overlay-00.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 To view the current status of any Internet-Draft, please check the 34 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 35 Directory, see http://www.ietf.org/shadow.html. 37 Abstract 39 Generalized MPLS defines both routing and signaling protocols for the 40 creation of Label Switched Paths (LSPs) in various transport 41 technologies. These protocols can be used to support a number of 42 deployment scenarios. This memo addresses the application of GMPLS 43 to the overlay model. 45 Contents 47 1 Introduction ........................................... 3 48 2 Addressing ............................................. 4 49 3 ERO Processing ......................................... 5 50 3.1 Path Message without ERO ............................... 6 51 3.2 Path Message with ERO .................................. 6 52 3.3 Explicit Label Control ................................. 6 53 4 RRO Processing ......................................... 6 54 5 Notification ........................................... 7 55 6 Connection Deletion .................................... 7 56 7 Security Considerations ................................ 7 57 8 Acknowledgments ........................................ 8 58 9 References ............................................. 8 59 9.1 Normative References ................................... 8 60 9.2 Informative References ................................. 8 61 10 Authors' Addresses ..................................... 9 63 1. Introduction 65 Generalized MPLS defines both routing and signaling protocols for the 66 creation of Label Switched Paths (LSPs) in various transport 67 technologies. These protocols can be used to support a number of 68 deployment scenarios. In a peer model, edge-nodes support both a 69 routing and a signaling protocol. The protocol interactions between 70 an edge-node and a core node are the same as between two core-nodes. 71 In the overlay model, the core-nodes act more as a closed system. 72 The edge nodes do not participate in the routing protocol instance 73 that runs among the core nodes; in particular, the edge nodes are 74 unaware of the topology of the core nodes. There may, however, be a 75 routing protocol interaction between a core node and an edge node for 76 the exchange of reachability information to other edge nodes. 78 Overlay Overlay 79 Network +----------------------------------+ Network 80 +----------+ | | +----------+ 81 | +----+ | | +-----+ +-----+ +-----+ | | +----+ | 82 | | | | | | | | | | | | | | | | 83 | --+ EN +-+-----+--+ CN +----+ CN +----+ CN +---+-----+-+ EN +-- | 84 | | | | +--+--| | | | | | | | | | | 85 | +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ | 86 | | | | | | | | | | 87 +----------+ | | | | | | +----------+ 88 | | | | | | 89 +----------+ | | | | | | +----------+ 90 | | | | +--+--+ | +--+--+ | | | 91 | +----+ | | | | | +-------+ | | | +----+ | 92 | | +-+--+ | | CN +---------------+ CN | | | | | | 93 | --+ EN +-+-----+--+ | | +---+-----+-+ EN +-- | 94 | | | | | +-----+ +-----+ | | | | | 95 | +----+ | | | | +----+ | 96 | | +----------------------------------+ | | 97 +----------+ Core Network +----------+ 98 Overlay Overlay 99 Network Network 101 Legend: EN - Edge Node 102 CN - Core Node 104 Figure 1: Overlay Reference Model 106 Figure 1 shows a reference network. The core network is represented 107 by the large box in the center. It contains five core-nodes marked 108 represent four islands of a single network overlaid network. Only 109 the nodes of this network with TE links into the core network are 110 shown. These nodes are called edge-nodes; the terminology is in 111 respect to the core network, not the overlay network. Note that each 112 box marked "Overlay Network" could contain many other nodes. Such 113 nodes are not shown; they do not participate in the signalling 114 described in this document. Only he edge-nodes can signal to set up 115 links across the core to other edge-nodes. Once a link is 116 established, presumably the edge-node will inform the other nodes of 117 the overlay network of its existence. How this is accomplished is 118 beyond the scope of this document. However using a forwarding 119 adjacency as described in [MPLS-HIER]. 121 In the overlay model there may be restrictions on what may be 122 signaled between an edge-node and a core-node. This memo addresses 123 the application of GMPLS to the overlay model. Specifically it 124 addresses RSVP procedures between an edge-node and a core-node in the 125 overlay model. All RSVP procedures are assumed to be identical to 126 [GMPLS-RSVP] except as noted in this document. 128 This document primarily addresses interactions between an edge-node 129 and it's adjacent (at the data plane) core-node. Except where noted, 130 the term core-node refers to the node which is immediately adjacent 131 to an edge-node across a particular data plane interface. The term 132 core-nodes, however, refers to all nodes in the core. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2. Addressing 140 Addresses for edge-nodes in the overlay model are drawn from the same 141 address space as the edge-nodes use to address their adjacent core- 142 nodes. This may be the same address space as used by the core-nodes 143 to communicate among themselves or it may be a VPN space supported by 144 the core-nodes as an overlay. 146 To be more specific, an edge-node and its attached core-node must 147 share the same address space which is used by GMPLS. A set of 148 tuples share the same address space if the 149 edge-nodes in the set could establish LSPs (through the core-nodes) 150 among themselves (note that edge-nodes in the set may be a subset of 151 all the edge-nodes). The address space used by the core-nodes to 152 communicate among themselves may, but need not be shared with the 153 address space used by any of the tuples. 155 An edge-node is identified by either a single IP address representing 156 its Node-ID, or by one or more numbered TE links that connect the 157 edge-node to the core-nodes. Core-nodes are assumed to be ignorant 158 of any other addresses associated with an edge-node (i.e. addresses 159 which are not used in signaling connections through the GMPLS core). 161 An edge-node need only know its own address, an address of the 162 adjacent core-node, and know (or be able to resolve) the address of 163 any other edge-node to which it wishes to connect. 165 A core-node need only know (and track) the addresses on interfaces 166 between that core-node and its attached edge-nodes, as well as the 167 Node IDs of those edge-nodes. In addition, a core-node needs to know 168 the interface addresses and Node IDs of other edge-nodes to which an 169 attached edge-node is permitted to connect. 171 When forming a SENDER_TEMPLATE the ingress edge-node includes either 172 its Node-ID or the address of one of its numbered TE links. In the 173 latter case the connection will only be made over this interface. 175 When forming a SESSION_OBJECT, the ingress edge-node includes either 176 the Node-ID of the egress edge-device or the address of one of the 177 egress' numbered TE links. In the latter case the connection will 178 only be made over this interface. The Extended_Tunnel_ID of the 179 SESSION Object is set to either zero or to an address of the ingress 180 edge-device. 182 Links may be either numbered or unnumbered. Further, links may be 183 bundled or unbundled. See [GMPLS-ARCH], [GMPLS-SIG], [BUNDLE], and 184 [RSVP-TE-UNUM]. 186 3. ERO Processing 188 An edge-node MAY include an ERO. A core-node MAY reject a Path 189 message that contains an ERO. Such behavior is controlled by 190 (hopefully consistent) configuration. If a core-node rejects a Path 191 message due to the presence of an ERO it SHOULD return an PathErr 192 message with an error code of "Unknown object class" toward the 193 sender. This causes the path setup to fail. 195 Further a core-node MAY accept EROs which only include the ingress 196 edge-node, the ingress core-node, the egress core-node and the egress 197 edge-node. This is to support explicit label control on the edge- 198 node interface, see below. If a core-node rejects a Path message due 199 to the presence of an ERO not of the permitted format it SHOULD 200 return an PathErr message with an error code of Bad Explicit Route 201 Object as defined in [RFC3209]. 203 3.1. Path Message without ERO 205 When a core-node receives a Path message from an edge-node that 206 contains no ERO, it MUST calculate a route to the destination and 207 include that route in a ERO, before forwarding the PATH message. One 208 exception would be if the egress edge-node were also adjacent to this 209 core-node. If no route can be found, the core-node SHOULD return a 210 PathErr message with an error code and value of 24,5 - "No route 211 available toward destination". 213 3.2. Path Message with ERO 215 When a core-node receives a Path message from an edge-node that 216 contains an ERO, it SHOULD verify the route against its topology 217 database before forwarding the PATH message. If the route is not 218 viable, then a PathErr message with an error code and value of 24,5 - 219 "No route available toward destination" should be returned. 221 3.3. Explicit Label Control 223 In order to support explicit label control and full identification of 224 the egress link an ingress edge-node may include an ERO that consists 225 of only the last hop. This is signaled by setting the first 226 subobject of the ERO to the node-ID of the egress core-node with the 227 L-bit set. Following this subobject are all other subobjects 228 necessary to identify the link and labels as they would normally 229 appear. 231 4. RRO Processing 233 An edge-node MAY include an RRO. A core-node MAY remove the RRO from 234 the Path message before forwarding it. Further the core-node may 235 remove the RRO from a Resv message before forwarding it to the edge- 236 node. Such behavior is controlled by (hopefully consistent) 237 configuration. 239 Further a core-node MAY edit the RRO in a Resv message such that it 240 includes only the subobjects from the egress core-node through the 241 egress edge-node. This is to allow the ingress node to be aware of 242 the selected link and labels on at the far end of the connection. 244 5. Notification 246 An edge-node MAY include a NOTIFY_REQUEST object in both the Path and 247 Resv messages it generates. A core-node MAY remove the 248 NOTIFY_REQUEST object from the Path or Resv message before forwarding 249 it. Core-nodes may send Notification messages to edge-nodes which 250 have included the NOTIFY_REQUEST object. 252 Further if no NOTIFY_REQUEST object is present in the Path or Resv 253 message (either because it was not included or because it was 254 removed) then the core-node adjacent to the edge-node may include a 255 NOTIFY_REQUEST object to set its value to its own address. 257 6. Connection Deletion 259 RSVP currently deletes connections using either a single pass 260 PathTear message, or a ResvTear and PathTear message combination. 261 Upon receipt of the PathTear message, a node deletes the connection 262 state and forwards the message. In optical networks, however, it is 263 possible that the deletion of a connection (e.g., removal of the 264 cross-connect) in a node may cause the connection to be perceived as 265 failed in downstream nodes (e.g., loss of frame, loss of light, 266 etc.). This may in turn lead to management alarms and perhaps the 267 triggering of restoration/protection for the connection. 269 To address this issue, the graceful connection deletion procedure 270 SHOULD be followed. Under this procedure, an ADMIN_STATUS object MUST 271 be sent in Path or Resv message along the connection's path to inform 272 all nodes enroute of the intended deletion, prior to the actual 273 deletion of the connection. The procedure is described in [GMPLS- 274 RSVP]. 276 7. Security Considerations 278 This draft imposes no new security risks over [GMPLS-RSVP]. In fact 279 it represents a lower trust model between the core and edge-nodes as 280 the core is permitted to hide its topology from the edge-nodes. The 281 core is also permitted to restrict the actions of edge-nodes by 282 filtering out specific RSVP objects. 284 8. Acknowledgments 286 The authors would like to thank Kireeti Kompella, Jonathan Lang, 287 Dimitri Papadimitriou, Dimitrios Pendarakis and Bala Rajagopalan for 288 their comments and input. 290 9. References 292 9.1. Normative References 294 [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - 295 Signaling Functional Description", Internet Draft, 296 draft-ietf-mpls-generalized-signaling-08.txt, 297 April 2002. 299 [GMPLS-RSVP] Ashwood-Smith, P. et. al, "Generalized MPLS - RSVP-TE 300 Signaling Functional Description", 301 draft-ietf-mpls-generalized-rsvp-te-07.txt, 302 April 2002. 304 [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol 305 -- Version 1 Functional Specification", RFC 2205, 306 September 1997. 308 [RFC2961] Berger, L. et al, "RSVP Refresh Overhead Reduction 309 Extensions", RFC 2961, April 2001 311 [RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for 312 LSP Tunnels", RFC 3209, December 2001. 314 9.2. Informative References 316 [GMPLS-ARCH] Mannie, E, et al., "Generalized Multi-Protocol 317 Label Switching (GMPLS) Architecture", Internet Draft, 318 draft-ietf-ccamp-gmpls-architecture-03.txt, Aug., 2002. 320 [MPLS-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with 321 MPLS TE", Internet Draft, 322 draft-ietf-mpls-lsp-hierarchy-08.txt, Sep., 2001. 324 [BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link 325 Bundling in MPLS Traffic Engineering", Internet Draft, 326 draft-ietf-mpls-bundle-04.txt, July, 2002. 328 [RSVP-UNNUM] Kompella, K., and Rekhter, Y., "Signalling Unnumbered 329 Links in RSVP-TE", Internet Draft, 330 draft-ietf-mpls-rsvp-unnum-07.txt, July, 2002. 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels," RFC 2119. 335 10. Authors' Addresses 337 338 John Drake 339 Calient Networks 340 5853 Rue Ferrari 341 San Jose, CA 95138 342 Phone: +1 408 972 3720 343 Email: jdrake@calient.net 345 Hirokazu Ishimatsu 346 Japan Telecom Co., Ltd. 347 2-9-1 Hatchobori, Chuo-ku, Tokyo, 104-0032, Japan 348 Tel: +81 3 5540 8493 349 Email: hirokazu.ishimatsu@japan-telecom.co.jp 351 Yakov Rekhter 352 Juniper Networks, Inc. 353 Email: yakov@juniper.net 355 George Swallow 356 Cisco Systems, Inc. 357 250 Apollo Drive 358 Chelmsford, MA 01824 359 Phone: +1 978 497 8143 360 Email: swallow@cisco.com